(This is a repost of an issue that was raised on golang-nuts but it didn't
get any responses there. minux had suggested to repost it here as a new
thread, since Russ (who's responsible for the go command) was away at the
time. I want to raise the issue because I think it could benefit from a
re-evaluation, given that the original decision was made when the situation
re gopath/goroot was very different. The following is a copy of the
original post by soapboxcicero.)

go build doesn't rebuild stale packages from outside the current gopath.

This was effected in
https://code.google.com/p/go/source/detail?r=a461bcce05f6 to fix issue

I see the logic of trying not to rebuild packages in go root, but I
don't see the reason for treating each directory in $GOPATH as a
"separate compilation world" (
https://code.google.com/p/go/source/browse/src/cmd/go/pkg.go#678 )

I'm more than willing to accept that there's a good reason for this,
but I don't see why it couldn't just skip files in the go root when
computing which packages are stale. This would also resolve issue 3149
without creating separate worlds.

The problem I'm running into is calling go build from other programs
with generated code.

I create the generated code in a directory in /tmp (via
ioutil.TempDir), add that directory to $GOPATH, and call go build.

I don't necessarily always know which $GOPATH is being worked in, so I
can't create the temp directory in that go path, and even if I did
there could still be surprises with stale packages in other workspaces
(though at least this would be a consistent surprise). Regardless, I'd
feel icky potentially leaving temp files in someone's work space if
there's a bug or a power outage.

My current solution is to use the -a flag on go build to force
rebuilding all dependencies. Though, now that I think about it, I have
not verified that this skips the separate worlds issue, can someone
confirm? Even if it does, it makes the compilation slower than it
could be. One option would be to duplicate the logic to see if
packages are stale in my library and figure out what has to be rebuilt
before doing anything else. I don't mind doing that but then the way
the library works is different from go build. I could force the user
of the library to specify which $GOPATH is being operated on (not that
that always makes sense) and only rebuild packages within that $GOPATH
to get parity back.

I don't really like any of those options. Preferably I'd like either
for go build to only treat the go root specially when computing stale
packages or to have some flag similar to -a but to operate as normal
but rebuild across work spaces.

Is there a rationale for treating each work space as separate worlds
instead of just skipping packages in go root? Is there a better
solution to my problem?

Thanks to Dmitri Shuralyov for bringing this to my attention, finding
issue 3149, and discussing options with me.


You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
postedApr 25, '14 at 2:08a
activeApr 25, '14 at 2:08a

1 user in discussion

Dmitri Shuralyov: 1 post



site design / logo © 2021 Grokbase