Replaces our serialization of child process
errors via Marshal with JSON, preventing
unintentional or malicious code execution outside
of the build sandbox.
Additionally, adds tests for the new behavior.
Adjust the rules based on the current codebase. Remove various enable,
disables and default values that are unnecessary. Add more comments
explaining why. Make minor changes needed to enable a few more rules.
Use 124 max line length everywhere. Also, reduce tap max line length to
189 as Homebrew/homebrew-core has that as a maximum now. In future
Homebrew/homebrew-core will also be reduced to 124 maximum line length.
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.
