cmd/go: detect when package or binary is stale due to removed source file
The go command uses file modification times to decide when a package is out of date: if the .a file is older than a source file, the .a file needs to be rebuilt. This scheme breaks down when multiple source files compile into a single .a file: if one source file is removed but no other changes are made, there is no indication that the .a file is out of date. The fix is to store a value called a build ID in the package archive itself. The build ID is a hash of the names of all source files compiled into the package. A later go command can read the build ID out of the package archive and compare to the build ID derived from the list of source files it now sees in the directory. If the build IDs differ, the file list has changed, and the package must be rebuilt. There is a cost here: when scanning a package directory, in addition to reading the beginning of every source file for build tags and imports, the go command now also reads the beginning of the associated package archive, for the build ID. This is at most a doubling in the number of files read. On my 2012 MacBook Pro, the time for 'go list std' increases from about 0.215 seconds to about 0.23 seconds. For executable binaries, the approach is the same except that the build ID information is stored in a trailer at the end of the executable file. It remains to be seen if anything objects to the trailer. I don't expect problems except maybe on Plan 9. Fixes #3895. Change-Id: I21b4ebf5890c1a39e4a013eabe1ddbb5f3510c04 Reviewed-on: https://go-review.googlesource.com/9154Reviewed-by: Ian Lance Taylor <iant@golang.org>
Showing
Please
register
or
sign in
to comment