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: go install -a always rebuilds standard library #12329

Closed
marcopeereboom opened this issue Aug 25, 2015 · 1 comment
Closed

cmd/go: go install -a always rebuilds standard library #12329

marcopeereboom opened this issue Aug 25, 2015 · 1 comment
Milestone

Comments

@marcopeereboom
Copy link

I used to use the -a flag on go install a lot because I tend to update go all the time and sometimes stuff got stale. I stopped using -a because it started rebuilding standard library which caused other interesting side effects. Anyway, I stopped using it but I now have a real use for it and I would like to know if either the documentation is wrong or if there is a bug.

For example in one of my toy projects:

$ go install -v -a ./...
runtime
errors
unicode
sync/atomic
unicode/utf8
...

It clearly goes and rebuilds all the standard library stuff before it gets to my code.

The documentation says:

        -a
                force rebuilding of packages that are already up-to-date.
                In Go releases, does not apply to the standard library.

So which is it?

@ianlancetaylor
Copy link
Contributor

The documentation is wrong.

Dup of #12203 .

@mikioh mikioh added this to the Go1.6 milestone Aug 29, 2015
@mikioh mikioh changed the title go install -a always rebuilds standard library cmd/go: go install -a always rebuilds standard library Aug 29, 2015
@golang golang locked and limited conversation to collaborators Sep 4, 2016
gopherbot pushed a commit that referenced this issue Dec 6, 2017
This CL makes "go install" behave the way many users expect:
install only the things named on the command line.
Future builds still run as fast, thanks to the new build cache (CL 75473).
To install dependencies as well (the old behavior), use "go install -i".

Actual definitions aside, what most users know and expect of "go install"
is that (1) it installs what you asked, and (2) it's fast, unlike "go build".
It was fast because it installed dependencies, but installing dependencies
confused users repeatedly (see for example #5065, #6424, #10998, #12329,
"go build" and "go test" so that they could be "fast" too, but that only
created new opportunities for confusion. We also had to add -installsuffix
and then -pkgdir, to allow "fast" even when dependencies could not be
installed in the usual place.

The recent introduction of precise content-based staleness logic means that
the go command detects the need for rebuilding packages more often than it
used to, with the consequence that "go install" rebuilds and reinstalls
dependencies more than it used to. This will create more new opportunities
for confusion and will certainly lead to more issues filed like the ones
listed above.

CL 75743 introduced a build cache, separate from the install locations.
That cache makes all operations equally incremental and fast, whether or
not the operation is "install" or "build", and whether or not "-i" is used.

Installing dependencies is no longer necessary for speed, it has confused
users in the past, and the more accurate rebuilds mean that it will confuse
users even more often in the future. This CL aims to end all that confusion
by not installing dependencies by default.

By analogy with "go build -i" and "go test -i", which still install
dependencies, this CL introduces "go install -i", which installs
dependencies in addition to the things named on the command line.

Fixes #5065.
Fixes #6424.
Fixes #10998.
Fixes #12329.
Fixes #18981.
Fixes #22469.

Another step toward #4719.

Change-Id: I3d7bc145c3a680e2f26416e182fa0dcf1e2a15e5
Reviewed-on: https://go-review.googlesource.com/75850
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
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