7df7cd6257
Instead of using a string to refer to an internal set defined in buildLisp, we just expose the relevant sets (as nix.buildLisp.sbcl, nix.buildLisp.ecl, …) and receive them as the `implementation` argument directly. This has several advantages: * It becomes easier to extend buildLisp, even for downstream users: Since you can just pass your own set, there's nothing stopping you from adding support for another implementation in a downstream derivation without having to edit the buildLisp file in any way which is great if you're using e. g. builtins.fetchGit to import it. * Users can mess with the implementation set by changing out some parts of it for customization purposes. Note that currently the sets use a lot of self-references which aren't even bound by a fix-point, so to make this work smoothly, we'd need to add some overriding mechanism. * The buildLisp code becomes quite a bit clearer. Since we're now always dealing with the implementation set, the confusing distinction between `impl`, `impl.name` and `implementation` no longer exists. `impl` is now exclusively an abbreviation of `implementation` (we could make this more consistent in the future even). Change-Id: I36d68069dd1315610b2f7159941507b465469b7c Reviewed-on: https://cl.tvl.fyi/c/depot/+/3368 Reviewed-by: tazjin <mail@tazj.in> Reviewed-by: grfn <grfn@gws.fyi> Tested-by: BuildkiteCI |
||
---|---|---|
.. | ||
binify | ||
bufCheck | ||
buildGo | ||
buildLisp | ||
buildManPages | ||
drvSeqL | ||
emptyDerivation | ||
escapeExecline | ||
getBins | ||
mergePatch | ||
netstring | ||
readTree | ||
runExecline | ||
runTestsuite | ||
tag | ||
tailscale | ||
utils | ||
writeElispBin | ||
writeExecline | ||
writers | ||
writeScript | ||
writeScriptBin | ||
yants | ||
OWNERS |