I hadn't planned to move on this so quickly but impressively core
today had its first Go Module using PR, so this has become more useful
than it would've been. Useful reading on the Modules system can be found
via https://golang.org/doc/go1.11#modules.
`GOCACHE` has been a thing for a while but it hasn't really been
especially beneficial to us, so I've ignored it, but with the Go Modules
system it can be incredibly useful in reducing build times & thus CI
burden. A lot of this is explained rather nicely here:
https://groups.google.com/forum/#!msg/golang-dev/RjSj4bGSmsw/KMHhU8fmAwAJ
The upsides here for us are obvious:
1) We do a *lot* of go-based builds, and the more things move over to the
module system the more comprehensive that cache will become and we'll
need to remotely fetch less dependencies, which massively speeds up
build times even on high-speed connections.
2) Module dependencies aren't limited per formula. If `hugo` fetches a
dependency that is the same version as, for example, `wiki` also needs
`wiki` won't bother to fetch that version remotely but instead will
simply pluck it out of the cache.
If we look at `hugo`, because it's the only formula so far with Module
support:
First build: `built in 1 minute 41 seconds`
Second build: `built in 14 seconds`.
It's worth noting perhaps that we can use just the module cache rather
than the build cache + module cache combination, but doing so leads to
a significant reduction in regained build time. A build under that
system pops an average build time with `hugo` (after the first build)
of ~70 seconds, which is only a 30 second saving on the first build.
However, if we wanted to speed up builds whilst also not eating big chunks
of disk space that is an option.
The downside of a build cache + module cache system is disk usage.
`go` does not exactly eat up disk space sparingly, and the cache size
from `hugo` alone is 258.8MB. That could be an issue on CIs where disk
space is already a squeeze at times, but it's not much different to how
we let the `java_cache` behave now.
All Module-supporting formulae need to do to use the shared cache is
instead of deleting the `GOPATH` env we set everywhere replace it with
this:
```
ENV["GOPATH"] = "#{HOMEBREW_CACHE}/go_cache"
```
`-Os` produces sometimes bigger binaries on Linux.
Also, llvm built with `-Os` is really slow at runtime for Linux.
Using `-02` aligns us with what Debian does, and as we are compiling most of our stuff with gcc (and not clang), it makes sense to use `-02` on Linux.
`-Os` does probably slightly different things when used on mac with llvm, compared to when it is used with gcc on Linux.
Instead of refusing to install software preemptively by assuming
multiple linkage to differing versions of the same library we now make
`brew linkage --test` verify that we don't have two versions of the
same library linked at the same time.
This will be considerably more permissive whilst checking the actual
problem that we're worried about.
If the formula to be retrieved was just version-bumped in the most
recent commit (HEAD), we would've ended up grabbing the second-most
recent version.
Instead, if the file already exists in tree at the current commit,
just construct the formula from that to get the version (for naming
purposes) and copy the file outright to its new location.
