4 ms·
That's only because the amount of Go code is small. Google builds all transitive dependencies from source in HEAD, so if there were 10 million lines of Go sitti
by cromwellian 13y ago
That's only because the amount of Go code is small. Google builds all transitive dependencies from source in HEAD, so if there were 10 million lines of Go sitting in the repository, your local workstation won't cut it.
It's not even the build times which are the most pressing issue these days, but the time for tests to run.
- nostrademons 13y agoOne of the major design goals for Go was that incremental compiles should not require a rebuild of all dependencies. I believe they bake interface information into the library files for this reason. If you don't change a file, you shouldn't need to rebuild it. If you sync to a later CL, you might need to rebuild what's changed, but even then all this should be cacheable across the company. Go was designed as a language to avoid a lot of the mess that the build tools have to deal with for C++.
- cromwellian 13y agoIn theory the same applies to Java, if I have a java_library, and none of the inputs have changed, I shouldn't have to rebuild anything. But the theory often doesn't match up to the reality with respect to objfs caching of dependencies in my experience. Also, any non-trivial app at Google is going to touch non-Go dependencies.