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: remove cross-GOPATH rebuild barrier #10509

Closed
rsc opened this issue Apr 20, 2015 · 3 comments
Closed

cmd/go: remove cross-GOPATH rebuild barrier #10509

rsc opened this issue Apr 20, 2015 · 3 comments
Labels
FrozenDueToAge
Milestone
Go1.5

Comments

@rsc
Copy link
Contributor

rsc commented Apr 20, 2015

The code at the bottom of isStale that bypasses the source file mtime checks was added to fix a bug (issue #3149) about writing to a system GOROOT, but the fix also (intentionally) separated out different GOPATH entries. This causes problems when people use fine-grained GOPATHs (not the common case, but also not something that should be broken), because installing a binary or package in one GOPATH uses stale packages from the other.

The system GOROOT has been the subject of many follow-on bugs and is now handled separately. We should remove the GOPATH barrier.
@rsc rsc self-assigned this Apr 20, 2015
@rsc rsc added this to the Go1.5 milestone Apr 20, 2015
@rsc rsc added the Started label Apr 20, 2015
@dmitshur
Copy link
Contributor

Thank you! This sounds incredibly good.

I will finally be able to go install my packages. I couldn't do that because of non-zero possibility of stale installed packages being used for compilation instead of the latest source code. This is also going to be immensely helpful for automated Go code generation and execution (e.g., see jimmyfrasche/goutil#2).

@dmitshur dmitshur mentioned this issue Apr 21, 2015
Open
@hyper0x
Copy link

hyper0x commented Apr 22, 2015

This is a great decision!! It will eliminate the barriers for a lot of third-party tools.

@gopherbot
Copy link

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

@ngrilly ngrilly mentioned this issue May 2, 2015
Closed
@jeremyschlatter jeremyschlatter mentioned this issue May 19, 2015
Open
@rsc rsc closed this as completed in 119daba Jun 4, 2015
This was referenced Jun 4, 2015
Closed
Closed
@dmitshur dmitshur mentioned this issue Jun 19, 2015
Closed
@fkautz fkautz mentioned this issue Jun 19, 2015
Closed
@dmitshur dmitshur mentioned this issue Aug 7, 2015
Merged
dmitshur added a commit to shurcooL/goexec that referenced this issue Aug 7, 2015
@dmitshur
Revert temporary solution to avoid stale builds, unneeded in Go 1.5.
be8fb0b 
This change depends on Go 1.5 being used.

In Go 1.5, a longstanding issue golang/go#10509 has been finally resolved!

Since the generated .go file resides somewhere in a temporary folder, it was
outside the GOPATH boundary, and if a package is built but stale (i.e. source
code has been changed since it was built), the stale version would've been used.

This reverts a temporary inefficient solution (95bb2b3)
of rebuilding absolutely all packages at all times just to avoid the risk of
incorrectly building with a stale package.

Resolves #3.
@dmitshur dmitshur mentioned this issue Aug 24, 2015
Merged
@dmitshur dmitshur mentioned this issue Feb 22, 2016
Merged
@liggitt liggitt mentioned this issue Mar 4, 2016
Closed
@golang golang locked and limited conversation to collaborators Jun 25, 2016
@rsc rsc removed their assignment Jun 23, 2022
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
4 participants
@rsc @hyper0x @dmitshur @gopherbot