cmd/go: no way to rebuild all of $GOPATH #8290
Labels
Milestone
Comments
See previous discussion https://groups.google.com/forum/#!searchin/golang-dev/tracey/golang-dev/xEoOzQwvsRI/moEwNBiLqLAJ |
CL https://golang.org/cl/151730045 mentions this issue. |
|
This issue was closed by revision 8c3005c. Status changed to Fixed. |
|
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 <[email protected]>
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jun 25, 2018
Today, 'go build -a my/pkg' and 'go install -a my/pkg' recompile not just my/pkg and all its dependencies that you wrote but also the standard library packages. Recompiling the standard library is problematic on some systems because the installed copy is not writable. The -a behavior means that you can't use 'go install -a all' or 'go install -a my/...' to rebuild everything after a Go release - the rebuild stops early when it cannot overwrite the installed standard library. During development work, however, you do want install -a to rebuild everything, because anything might have changed. Resolve the conflict by making the behavior of -a depend on whether we are using a released copy of Go or a devel copy. In the release copies, -a no longer applies to the standard library. In the devel copies, it still does. This is the latest in a long line of refinements to the "do I build this or not" logic. It is surely not the last. Fixes golang#8290. LGTM=r R=golang-codereviews, r, tracey.brendan CC=adg, golang-codereviews, iant https://golang.org/cl/151730045
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jun 26, 2018
Today, 'go build -a my/pkg' and 'go install -a my/pkg' recompile not just my/pkg and all its dependencies that you wrote but also the standard library packages. Recompiling the standard library is problematic on some systems because the installed copy is not writable. The -a behavior means that you can't use 'go install -a all' or 'go install -a my/...' to rebuild everything after a Go release - the rebuild stops early when it cannot overwrite the installed standard library. During development work, however, you do want install -a to rebuild everything, because anything might have changed. Resolve the conflict by making the behavior of -a depend on whether we are using a released copy of Go or a devel copy. In the release copies, -a no longer applies to the standard library. In the devel copies, it still does. This is the latest in a long line of refinements to the "do I build this or not" logic. It is surely not the last. Fixes golang#8290. LGTM=r R=golang-codereviews, r, tracey.brendan CC=adg, golang-codereviews, iant https://golang.org/cl/151730045
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jul 9, 2018
Today, 'go build -a my/pkg' and 'go install -a my/pkg' recompile not just my/pkg and all its dependencies that you wrote but also the standard library packages. Recompiling the standard library is problematic on some systems because the installed copy is not writable. The -a behavior means that you can't use 'go install -a all' or 'go install -a my/...' to rebuild everything after a Go release - the rebuild stops early when it cannot overwrite the installed standard library. During development work, however, you do want install -a to rebuild everything, because anything might have changed. Resolve the conflict by making the behavior of -a depend on whether we are using a released copy of Go or a devel copy. In the release copies, -a no longer applies to the standard library. In the devel copies, it still does. This is the latest in a long line of refinements to the "do I build this or not" logic. It is surely not the last. Fixes golang#8290. LGTM=r R=golang-codereviews, r, tracey.brendan CC=adg, golang-codereviews, iant https://golang.org/cl/151730045
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jul 30, 2018
Today, 'go build -a my/pkg' and 'go install -a my/pkg' recompile not just my/pkg and all its dependencies that you wrote but also the standard library packages. Recompiling the standard library is problematic on some systems because the installed copy is not writable. The -a behavior means that you can't use 'go install -a all' or 'go install -a my/...' to rebuild everything after a Go release - the rebuild stops early when it cannot overwrite the installed standard library. During development work, however, you do want install -a to rebuild everything, because anything might have changed. Resolve the conflict by making the behavior of -a depend on whether we are using a released copy of Go or a devel copy. In the release copies, -a no longer applies to the standard library. In the devel copies, it still does. This is the latest in a long line of refinements to the "do I build this or not" logic. It is surely not the last. Fixes golang#8290. LGTM=r R=golang-codereviews, r, tracey.brendan CC=adg, golang-codereviews, iant https://golang.org/cl/151730045
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: