-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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: remove cross-GOPATH rebuild barrier #10509
Comments
Thank you! This sounds incredibly good. I will finally be able to |
This is a great decision!! It will eliminate the barriers for a lot of third-party tools. |
CL https://golang.org/cl/9155 mentions this issue. |
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.
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.
The text was updated successfully, but these errors were encountered: