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.

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

cmd/go: Rebuild third party packages after a new release #3036

Closed
gopherbot opened this issue Feb 15, 2012 · 7 comments
Closed

cmd/go: Rebuild third party packages after a new release #3036

gopherbot opened this issue Feb 15, 2012 · 7 comments
Milestone

Comments

@gopherbot
Copy link

by raul.san@sent.com:

When you build a new release, the third party packages (in $GOPATH) should be re-built
automatically. So it's far easy to detect brocken packages due to new changes in that
last release.

Note that `go install -a ...` compiles again the packages in Go core.

http://groups.google.com/group/golang-nuts/browse_thread/thread/b694b607e19214e
@minux
Copy link
Member

minux commented Feb 15, 2012

Comment 1:

I think the go tool really need to detect the situation where the current pkg archive,
though more recent 
than their sources, should be recompiled, because the loader will refuse it due to
version mismatch.
(Or better yet, detect if the recompile is really needed; but I think this check is very
very difficult to do)
And if this is fixed, you can just 'go install ...' to update your code whenever you
update to a new version.

@dsymonds
Copy link
Contributor

Comment 2:

Labels changed: added priority-go1, removed priority-triage.

Status changed to Thinking.

@dsymonds
Copy link
Contributor

Comment 3:

Labels changed: added toolbug.

@rsc
Copy link
Contributor

rsc commented Mar 1, 2012

Comment 5:

This issue was closed by revision b03a5f6.

Status changed to Fixed.

@gopherbot
Copy link
Author

Comment 6 by rogerpack2005:

today, it just seems to complain about mismatch, not do an auto rebuilt [FWIW]...

@gopherbot
Copy link
Author

Comment 7 by unit0x03:

Agree, I'm still seeing behaviour where it doesn't update and re-install libraries
installed by a previous release.

@rsc rsc added this to the Go1 milestone Apr 10, 2015
@rsc rsc removed the priority-go1 label Apr 10, 2015
@gopherbot
Copy link
Author

CL https://golang.org/cl/10761 mentions this issue.

rsc added a commit that referenced this issue Jun 15, 2015
This CL adds a very long comment explaining how isStale and
the new build IDs work. As part of writing the comment I realized:

// When the go command makes the wrong build decision and does not
// rebuild something it should, users fall back to adding the -a flag.
// Any common use of the -a flag should be considered prima facie evidence
// that isStale is returning an incorrect false result in some important case.
// Bugs reported in the behavior of -a itself should prompt the question
// ``Why is -a being used at all? What bug does that indicate?''

The two uses of -a that are most commonly mentioned in bugs filed
against the go command are:

	go install -a ./...
	go build -tags netgo -a myprog

Both of these commands now do the right thing without needing -a.

The -a exception we introduced in Go 1.4 was for the first form, and
it broke the second form. Again, neither needs -a anymore, so restore
the old, simpler, easier to explain, less surprising meaning used in Go 1.3:
if -a is given, rebuild EVERYTHING.

See the comment for more justification and history.

Summary of recent CLs (to link bugs to this one):

Fixes #3036. Now 'go install ./...' works.
Fixes #6534. Now 'go install ./...' works.
Fixes #8290. Now 'go install ./...' works.
Fixes #9369. Now 'go build -tags netgo myprog' works.
Fixes #10702. Now using one GOPATH with Go 1.5 and Go 1.6 works.
  (Each time you switch, everything needed gets rebuilt.
  Switching from Go 1.4 to Go 1.5 will rebuild properly.
  Switching from Go 1.5 back to Go 1.4 still needs -a when
  invoking the Go 1.4 go command.)

Change-Id: I19f9eb5286efaa50de7c8326602e94604ab572eb
Reviewed-on: https://go-review.googlesource.com/10761
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants