Closed
Description
The review for CL 107628 reminded me of this idea,so I wanted to make a quick note of it.
I think that this:
// +build (!arm64 && !s390x) || (arm64 && !go1.11) || gccgo || appengine
Would be a lot easier for a Go developer to parse (and verify) than the current syntax we use for build tags:
// +build !arm64,!s390x arm64,!go1.11 gccgo appengine
Build tags are hard to test so we should make them as easy to review as possible.
This might be a Go 2 suggestion, but it could probably also be added to Go 1. For Go 2 I would also be tempted to remove multi-line build tags which are also difficult for Go developers to parse.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
robpike commentedon May 11, 2018
I agree that the build tag logic is too cutesy but it's hard to change outright. It might be possible to support both forms transparently, or to use a different keyword such as +build2.
I never liked the current form. I'm not even sure I could ever do anything complex without reading the docs carefully.
AlexRouSg commentedon May 11, 2018
Instead of
+build2
, if there's going to be a new keyword anyway, lets take this chance to be consistent and have something likego:build
cznic commentedon May 11, 2018
I don't like the current syntax at all, but breaking every 3rd part tool relying on it, created in the last nearly decade, shouldn't be taken lightly. Ugly syntax or not - it's not broken.
Also, going from a regular language to a CF one may result in some tools/scripts never getting fixed/upgraded with a full parser.
rsc commentedon May 21, 2018
I'm sorry for the old syntax, but I was trying to keep people from doing very complex things. Probably that was a mistake, but the current syntax is general enough that we probably shouldn't add a second one.
josharian commentedon May 21, 2018
Perhaps someone could write a simple third party tool that accepts a simpler syntax on the command line (with && and ||) and spits out appropriate build tag lines.
josharian commentedon May 21, 2018
And as a bonus if the tool also went the other way, you could have a very nice IDE integration, in which you could simply edit pseudo-build tags. cc @mvdan @dominikh @fatih
mvdan commentedon May 22, 2018
Would be great if this was part of
x/tools
, since it seems like the main users would be the official Go repos themselves. Perhapsx/tools/cmd/buildtags
?mengzhuo commentedon May 25, 2018
@josharian you might need to consider "go version" in build tags is different from what it looks like.
!go1.11 seems to be ( go1.x < go1.11 )
however it really means NOT ( if go1.x in ( go1.1 to go1.11) )
rsc commentedon Jun 4, 2018
As I said above, introducing and encouraging extra complexity here is probably not a win. I think we should leave well enough alone.
robpike commentedon Jun 4, 2018
All proposals add complexity.
But for the record: This is just the kind of change that could add clarity to the code in Go 2.
39 remaining items