Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cmd/go: argument "-tags" doesn't trigger rebuild even if tags are different from last build #11165

Closed
ghost opened this issue Jun 11, 2015 · 6 comments
Closed

cmd/go: argument "-tags" doesn't trigger rebuild even if tags are different from last build #11165

ghost opened this issue Jun 11, 2015 · 6 comments
Labels
FrozenDueToAge
Milestone
Go1.5

Comments

@ghost
Copy link

ghost commented Jun 11, 2015

So if you setup a project that has some file that use -tags
argument. reinstalling/building will not trigger a rebuild of the library even if the -tags provided are different from the last build
to reproduce:
define 2 files in a package, each one with a function that returns a different value
eg.

// +build alice

package thebug
func Bob()bool {return true}

// +build !alice

package thebug
func Bob()bool {return false}

then make some simple main that simply calls this function and prints the result
then compile the library
$ go install thebug//should build with the !alice version
$ go run main.go
false
$ go install -tags alice thebug
$ go run main.go
false
notice that thebug was not recompiled (because no files changed) the only workaround i found was to build using the -a flag but that's a pain when the library you're compiling import many other library.
@adg adg changed the title go build/install argument "-tags" doesn't trigger rebuild even if tags are different from last build cmd/go: argument "-tags" doesn't trigger rebuild even if tags are different from last build Jun 11, 2015
@adg
Copy link
Contributor

adg commented Jun 11, 2015

I think the work that @rsc is doing with content-addressable build objects will solve this issue.

@bradfitz
Copy link
Contributor

This bug report doesn't include which version of Go that @hydroflame was using.

This might've already been fixed in 119daba or 7b87631 on April 20th.

@ghost
Copy link
Author

ghost commented Jun 11, 2015

hydroflame$ go version
go version go1.4.2 darwin/amd64

@adg
Copy link
Contributor

adg commented Jun 11, 2015

Seems likely that it is fixed at HEAD. Closing the issue until someone reports otherwise.

@adg adg closed this as completed Jun 11, 2015
@minux
Copy link
Member

minux commented Jun 12, 2015

Have you tried Go 1.5 (tip)? I think the issue has been fixed.

Update: confirmed fixed at tip.

@mikioh mikioh added this to the Go1.5 milestone Jun 13, 2015
oconnor663 added a commit to keybase/client that referenced this issue Sep 23, 2015
@oconnor663
always use -a for packaging builds
a0ddd27 
Prior to 1.5, Go fails to rebuild binaries when tags change:
golang/go#11165

The only safe way to build is to force Go to rebuild everything, every
time. Note that "when tags change" is a tricky concept. If you run
`go get`, you just did an implicit build with no tags. So if you run
`go build -tags foo` immediately after, *your tags have changed*, even
though you think you only did one build. Your "clean" GOPATH is not
safe!
@oconnor663
Copy link

I just ran into this building on Debian (go1.3.3). This bug can even affect build machines that try to use a clean GOPATH, if they use go get to assemble it, because go get implicitly runs a build with no tags. I think this is severe enough that the documentation for -tags needs a warning about using it without -a.

@golang golang locked and limited conversation to collaborators Sep 23, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.5
Development

No branches or pull requests
6 participants
@bradfitz @mikioh @minux @oconnor663 @adg @gopherbot