Users can supply a list of foreign dependencies in calls to
buildGo.external. These are now appropriately inserted into packages
that *need them* and no further, resolving issues with complex
internal recursion in some repositories!
This error is returned by the build analysis logic if the target
package does not have any relevant Go files, which might be the case
if `+build` flags and such are used.
Changes in the structure of buildGo.external meant that the package
layout for the protobuf library is now slightly different.
`proto` has been amended to work with the new structure. Callers of
buildGo.proto do not need to be updated (i.e. the example still
works).
Implements a builder function that calls the analysis tool on the
provided source and builds up the required attribute set, including
local dependencies.
Fixes the prefix trimming logic for package names and source files if
the source files appear in the package root (which is, unsurprisingly,
very common).
Due to the lexical walk order of `filepath.Walk` the previous
directory identification logic failed under certain conditions if the
top-level directory contained Go files that showed up *after* the
first subdirectories.
To simplify the logic a set of directories is now gathered instead on
a file-level.
Sub-packages of external dependencies are traversed by Nix as a tree
of attribute sets which need to be accessed by "path". To make this
easier, the dependency analyser now returns "paths" as string lists.
Adds a tool that can analyse dependencies that were not originally
meant to be built with buildGo.nix and return information that can be
used to construct appropriate Nix dependencies.
The tool will return information about package-local and foreign
dependencies separately to let Nix determine whether all required
dependencies are provided and to correctly link together sub-packages.
To avoid listing standard library imports in the dependencies, a list
of all packages in the standard library is generated statically to
allow for those to be filtered out during the analysis.
This tool is still work-in-progress.
Adds an alternative implementation of a builder for external packages
which traverses packages and builds up an attribute set tree out of
their structure.
Currently this is not functional because there is no useable method of
specifying dependencies within that package set.
This makes it possible to override arguments to the Go builders
downstream in the style of `overrideAttrs` from standard nixpkgs
derivations.
For example, given a Nix value `foo` that builds a binary called `foo`
the name of this binary could be changed and a new dependency on
`somelib` added like so:
foo.overrideGo(old: {
name = "bar";
deps = old.deps ++ [ somelib ];
})
Moves the Protobuf & gRPC dependencies to a separate file which uses
buildGo.external to build the dependencies.
The versions are pinned at master of 2019-11-26.
Adds two new parameters to buildGo.external:
* `srcOnly` toggles whether the created derivation should contain only
the source code, or the built package.
This is useful in situations where some sub-packages of a larger
package are needed and the build should be deferred to the package
depending on them.
It defaults to false, meaning that external packages are built by
default.
* `targets` controls which "sub-packages" of the target package are
built. It defaults to building all sub-packages.
Adds a buildGo.external function that can build packages following the
default go-tool package layout. Dependencies work the same way as they
do for other buildGo-packages, but instead of being passed straight to
the compiler a fake GOPATH is assembled using a symlink forest.
External currently supports very few direct configuration options and
was primarily created to build the protobuf packages, but it is also
useful for including external dependencies in buildGo-native projects.
The previous complex build logic for the protobuf package has been
replaced with a call to `external`.
Adds a 'buildGo.proto' function which takes a single .proto file as
its source and generates a corresponding Go library which can then be
imported.
'proto' takes these arguments (Yants-style type definition):
struct "protoArgs" {
# required:
name = string;
proto = path;
# optional:
extraDeps = list goLib; # defaults to [ ]
protocFlags = option string;
}
Note that proto libraries will automatically have dependencies for the
required protobuf Go libraries added to them.
gRPC is not (yet) supported.