• Russ Cox's avatar
    cmd/go: switch to entirely content-based staleness determination · 7dea5097
    Russ Cox authored
    This CL changes the go command to base all its rebuilding decisions
    on the content of the files being processed and not their file system
    modification times. It also eliminates the special handling of release
    toolchains, which were previously considered always up-to-date
    because modification time order could not be trusted when unpacking
    a pre-built release.
    
    The go command previously tracked "build IDs" as a backup to
    modification times, to catch changes not reflected in modification times.
    For example, if you remove one .go file in a package with multiple .go
    files, there is no modification time remaining in the system that indicates
    that the installed package is out of date. The old build ID was the hash
    of a list of file names and a few other factors, expected to change if
    those factors changed.
    
    This CL moves to using this kind of build ID as the only way to
    detect staleness, making sure that the build ID hash includes all
    possible factors that need to influence the rebuild decision.
    
    One such factor is the compiler flags. As of this CL, if you run
    
    	go build -gcflags -N cmd/gofmt
    
    you will get a gofmt where every package is built with -N,
    regardless of what may or may not be installed already.
    
    Another such factor is the linker flags. As of this CL, if you run
    
    	go install myprog
    	go install -ldflags=-s myprog
    
    the second go install will now correctly build a new myprog with
    the updated linker flags. (Previously the installed myprog appeared
    up-to-date, because the ldflags were not included in the build ID.)
    
    Because we have more precise information we can also validate whether
    the target of a "go test -c" operation is already the right binary and
    therefore can avoid a rebuild.
    
    This CL sets us up for having a more general build artifact cache,
    maybe even a step toward not having a pkg directory with .a files,
    but this CL does not take that step. For now the result of go install
    is the same as it ever was; we just do a better job of what needs to
    be installed.
    
    This CL does slow down builds a small amount by reading all the
    dependent source files in full. (The go command already read the
    beginning of every dependent source file to discover build tags
    and imports.) On my MacBook Pro, before this CL all.bash takes
    3m58s, while after this CL and a few optimizations stacked above it
    all.bash takes 4m28s. Given that CL 73850 cut 1m43s off the all.bash
    time earlier today, we can afford adding 30s back for now.
    More optimizations are planned that should make the go command
    more efficient than it was even before this CL.
    
    Fixes #15799.
    Fixes #18369.
    Fixes #19340.
    Fixes #21477.
    
    Change-Id: I10d7ca0e31ca3f58aabb9b1f11e2e3d9d18f0bc9
    Reviewed-on: https://go-review.googlesource.com/73212
    Run-TryBot: Russ Cox <rsc@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: 's avatarDavid Crawshaw <crawshaw@golang.org>
    7dea5097
inline_callers.go 1.9 KB