Create a store path where the executable `exe` is linked to
$out/bin/${name}. This is useful for e.g. including it as a “package”
in `buildInputs` of a shell.nix.
For example, if I have the exeutable /nix/store/…-hello, I can make it
into /nix/store/…-binify-hello/bin/hello with
`binify { exe = …; name = "hello" }`.
Change-Id: I600bdcd8f143bca2dd8dfbb165a9a5a8d6397622
Reviewed-on: https://cl.tvl.fyi/c/depot/+/624
Reviewed-by: tazjin <mail@tazj.in>
These functions work like buildGo.program & buildGo.package, but run
the .go2 sources through go2go first before passing them to the
//nix/buildGo equivalents.
Change-Id: Id1ebab6085c390d6986387370181377b9f5d39e8
This skips any directory entries starting with a dot.
Change-Id: I95767f3d35bcb2ed9b3d6e772f3924dd57612711
Reviewed-on: https://cl.tvl.fyi/c/depot/+/123
Reviewed-by: tazjin <mail@tazj.in>
Prior to this patch, github.com/hashicorp/terraform-svchost is
erroneously considered a sub-package of github.com/hashicorp/terraform,
breaking dependency searching:
error: missing local dependency 'github.com.hashicorp.terraform-svchost' in 'github.com/hashicorp/terraform'
Change-Id: Ibcf0f3a9b1742ce46f84cbbf84e90127b8c1df0d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/122
Reviewed-by: tazjin <mail@tazj.in>
This subtree split makes it possible for people to clone only
yants (similar to the kontemplate and journaldriver branches).
The subtree continues the history of the old git repository.
Setting the GOROOT_FINAL environment variables replaces the absolute
location of the Go standard library sources in the final build
artefacts with a fake location (in this case starting with
go/src/...).
This is despite the documentation for 'trimpath' (in 'go tool
compile') stating that it would affect all source paths: That's only
true for user code!
I figured this out by reading through the implementation of the other
'trimpath' (in 'gob build'):
https://go-review.googlesource.com/c/go/+/173345
Adds the necessary attributes on derivations created by
buildLisp.program for them to be passed to buildLisp.sbclWith.
This makes it possible to easily spin up Lisp environments that
contain everything needed for a given program.
I can not currently find a way to set the CFFI variables correctly to
get it to load libraries from Nix.
In the absence of that feature, a wrapper also does the trick.
It's not enough to compile in the right order - turns out you also
have to load the compiled objects in the right order.
To achieve this some cursed code has been added that changes the Lisp
generated by Nix to compile the other Lisp so that it also generates
some bash, which Nix can then use to concatenate the FASLs in the
right order to feed them to Lisp again.
It works but I'll replace it with a more elegant solution once one is
needed.
Similar to buildGo.nix, the library derivations carry information
about their dependencies which is merged when a load file is
instantiated.
The load files are created when compiling libraries, but will in the
future also be created when wrapping SBCL and dumping images.
Adds a Nix function to build a Lisp library out of a specified set of
Nix files. All files are combined into a single FASL.
This is by design only compatible with SBCL (for now).
This moves the various projects from "type-based" folders (such as
"services" or "tools") into more appropriate semantic folders (such as
"nix", "ops" or "web").
Deprecated projects (nixcon-demo & gotest) which only existed for
testing/demonstration purposes have been removed.
(Note: *all* builds are broken with this commit)
