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
The -x go option prints all intermediate commands used by the Go
compiler. For instance, this is pretty useful to debug Go LD_FLAGS
because the used linker command is printed.
This adds a fairly basic build for just the binaries for the Google
Cloud Print CUPS connector (gcp-cups-connector), and gcp-connector-util
to set it up in the first place. In the future I would like to
streamline the configuration more and make gcp-cups-connector a
proper NixOS service - as right now it must be run by hand.
As a user installing the program it's not interesting what go version it
was compiled against. Not more interesting than any other potential
dependencies. It also makes it harder to install or update the package.
After #16017 there were a lot
of comments saying that `nix` would be better than `JSON`
for Go packages dependency sets.
As said in https://github.com/NixOS/nixpkgs/pull/16017#issuecomment-229624046
> Because of the content-addressable store, if two programs have the
> same dependency it will already result in the same derivation in
> the
> store. Git also has compression in the pack files so it won't make
> much difference to duplicate the dependencies on disk. And finally
> most users will just use the binary builds so it won't make any
> differences to them.
This PR removes `libs.json` file and puts all package dependencies in
theirs `deps.json`.
