Simpler method of setting tags rather than using some combination of buildFlags, buildFlagsArray, preBuild, etc
Using `lib.concatStringsSep ","` as space separated tags are deprecated in go.
Previously it was not possible to define multiple ldflags, since only
the last definition applies, and there's some quoting issues with
`buildFlagsArray`. With the new `ldflags` argument it's possible to do
this, e.g.
ldflags = drv.ldflags or [] ++ [
"-X main.Version=1.0"
]
can now properly append a flag without clearing all previous ldflags.
When building a go binary that's linking against some .so/.a, while
cross-compiling, we need to pass the correct compiler, otherwise
`go build` will fail with the not-so helpful error message:
```
gcc_arm64.S: Assembler messages:
gcc_arm64.S:28: Error: no such instruction: `stp x29,x30,[sp,'
gcc_arm64.S:32: Error: too many memory references for `mov'
gcc_arm64.S:34: Error: no such instruction: `stp x19,x20,[sp,'
gcc_arm64.S:37: Error: no such instruction: `stp x21,x22,[sp,'
gcc_arm64.S:40: Error: no such instruction: `stp x23,x24,[sp,'
gcc_arm64.S:43: Error: no such instruction: `stp x25,x26,[sp,'
gcc_arm64.S:46: Error: no such instruction: `stp x27,x28,[sp,'
gcc_arm64.S:50: Error: too many memory references for `mov'
gcc_arm64.S:51: Error: too many memory references for `mov'
gcc_arm64.S:52: Error: too many memory references for `mov'
gcc_arm64.S:54: Error: no such instruction: `blr x20'
gcc_arm64.S:55: Error: no such instruction: `blr x19'
gcc_arm64.S:57: Error: no such instruction: `ldp x27,x28,[sp,'
gcc_arm64.S:60: Error: no such instruction: `ldp x25,x26,[sp,'
gcc_arm64.S:63: Error: no such instruction: `ldp x23,x24,[sp,'
gcc_arm64.S:66: Error: no such instruction: `ldp x21,x22,[sp,'
gcc_arm64.S:69: Error: no such instruction: `ldp x19,x20,[sp,'
gcc_arm64.S:72: Error: no such instruction: `ldp x29,x30,[sp],'
```
This is done in response to complaints that the module format is not
human readable. The vendor source blob is flat files and should be
extremely readable.
The builder does not technically need the modSha256 of the vendor dir, and even
though we pass it the entire vendor dir it makes sense not to risk having an
accidental dependency on that variable.
However, tools like [nixpkgs-update](https://github.com/ryantm/nixpkgs-update)
need to inspect the `modSha256` of a package in order to be able to update them,
and since this is a real part of the package (describes info about its
dependencies) let's add it to `passthru`.
Specifically, this allows us to run a cmd like `nix eval -f . tflint.modSha256`
to get the current value, which is how the bot finds it to replace with the new
version in the Rust ecosystem.
When modSha256 is null, disable the nix sandbox instead of using a
fixed-output derivation. This requires the nix-daemon to have
`sandbox = relaxed` set in their config to work properly.
Because the output is (hopefully) deterministic based on the inputs,
this should give a reproducible output. This is useful for development
outside of nixpkgs where re-generating the modSha256 on each mod.sum
changes is cumbersome.
Don't use this in nixpkgs! This is why null is not the default value.
Since Go 1.13, `GOSUMDB` defaults to "sum.golang.org", to consult the
checksum database of the main module's go.sum.
We already use the default behavior when building `go-modules`, but Go
tries to consult the checksum database again when building the module,
and fails because since it requires `cacert` and `git` which are not
propagated when building the package.
Since GO 1.13, the go command caches the lookup results and tiles in
$GOPATH[1], hence making the module directory non-deterministic.
Use the `-f` flag when removing /sumdb, for compatibility with Go 1.12
because in that version does not exists that directory.
[1] https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md#command-client
When $subPackages has more than one item, the build was failing because
./ was added only to the first subPackage. This commit adds ./ to all
specified subPackages.
For some Go projects a go.mod file is included but there are no listed
dependencies. When this is encountered the Go toolchain will not create
a cache folder for downloaded dependencies which causes buildGoModule to
fail.
An example of a project like this that is widely used is:
https://github.com/golang/protobuf
This commit adds a mkdir command to ensure that the directory always
exists so it can be copied and prevent the failure.
cacert already exposes NIX_SSL_CERT_FILE in its setupHook. Fetchers and builders are already setup to use this variable and there's no need to export them manually.
The function buildGoModule builds Go programs managed with Go modules. It builds
a Go module through a two phase build:
- An intermediate fetcher derivation. This derivation will be used to
fetch all of the dependencies of the Go module.
- A final derivation will use the output of the intermediate derivation
to build the binaries and produce the final output.
This change moves buildGoPackage from pkgs/development/go-modules to
pkgs/development/go-packages, so we can have buildGoModule at
pkgs/development/go-modules.
I noticed that I was seeing the Go compiler build things in parallel even when I'd set `-j1 --cores 1`. It appears that the compiler, by default, uses the number of CPUs that are available to perform a build, while nixpkgs parallelizes at the directory level.
In order to change the fewest assumptions, this explicitly tells the Go compiler to run single-threaded. The flag's documentation is:
```
-p n
the number of programs, such as build commands or
test binaries, that can be run in parallel.
The default is the number of CPUs available.
```
So this should function as expected. Feedback appreciated!
If projects uses go1.11 modules GOCACHE is required.
Also if buildGoPackage is used in a nix-shell setting we don't
want to override GOCACHE to allow incremental builds.
This should be backported to 18.09
