The go compiler doesn't like it when you mix the two, and Travis CI does
exactly that. Take advantage of the opportunity to disable it everywhere
else as well.
When go autodetects that it is being run as a go mod, and that there is
a vendor directory, it will still try to redownload all sources over the
network, unless you use -mod=vendor to tell it to use that. Additionally,
when using -mod=vendor the compiler will nicely avoid messing with
$GOPATH at all, since it can operate in a completely self-contained
manner.
Take advantage of this, when the detected go version is at least 1.11
(when the -mod flag was introduced).
This caused gcc to receive the actual argument "''" or for example
"'-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'" and then error
with
gcc: error: '-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now': No such file or directory
Furthermore, the trimpath arguments tried to trim an actual path
resembling "'$PWD'", which did nothing as the literal single quotes were
not valid in this context.
Both issues can be fixed by assigning arguments to the go compiler using
the argv notation { "-flag", "argument" } rather than { "-flag=argument" }.
Go 1.10 release notes:
> The go build -asmflags, -gcflags, -gccgoflags, and -ldflags options
> now apply by default only to the packages listed directly on the
> command line. For example, go build -gcflags=-m mypkg passes the
> compiler the -m flag when building mypkg but not its dependencies. The
> new, more general form -asmflags=pattern=flags (and similarly for the
> others) applies the flags only to the packages matching the pattern.
> For example: go install -ldflags=cmd/gofmt=-X=main.version=1.2.3
> cmd/... installs all the commands matching cmd/... but only applies
> the -X option to the linker flags for cmd/gofmt. For more details, see
> go help build.
golang does not natively respect LDFLAGS, but you can pass them on the
command line using -ldflags=-extldflags=...
This is important for distributions, in order to provide common
functionality such as hardening flags.
Also strip the prefixed root source directory from the embedded source
file paths. This is not important information for the debugger, which
should only care about paths relative to $GOPATH, and results in less
build environment metadata leaking into the final binary. (This also
aids in reproducible builds when using different build directories, see
e.g. https://github.com/golang/go/issues/16860)
If the environment variable SOURCE_DATE_EPOCH is set in the build
environment, prefer it over the current date when determining the
correct timestamp to use as the date the manpages were built.
See https://reproducible-builds.org/specs/source-date-epoch/
by a factor of 3
Without this patch, using make -j
built every man page and html page 25 times
Now, man pages are always generated in a single ronn call
after all .ronn files are made.
Workarounds GNU make bug https://savannah.gnu.org/bugs/?54854
This was from the time when we tried to have hub build even if it wasn't
checkout out within a local GOPATH. This change assumes a working Go
environment.
The only thing that has substansively changed is that Go 1.8 handles
redirect logic more safely than previous versions. This means we can
drop our special handling to avoid following redirects to other
domains. We were only doing that to protect against the possibility
of leaking auth headers. With Go 1.8, the auth headers are not
forwarded when following a redirect to another domain, so we don't
need our special handling any more.
As long as people are attempting to build with the Makefile, the new
check_go_version script should cause the build to stop if our
collaborators aren't using at least version 1.8 of go.
It wraps functionality already provided by "hub checkout". The advantage
with "hub review" are twofold:
* Discoverability. It wasn't until I started browsing the hub source
code that I realized this functionality was present.
* Usability. Just typing the PR number is easier than having to figure
out its URL.