| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
For every implementation we support an extra passthru attribute with the
name of the implementation is created which points to a version of the
derivation built with that implementation. E. g. if we support CCL, ECL
and SBCL, third_party.lisp.alexandria would have:
* third_party.lisp.alexandria.sbcl
* third_party.lisp.alexandria.ecl
* third_party.lisp.alexandria.ccl
To make this possible, the REPL derivation which was called `sbcl`
originally has been renamed to `repl`.
Since some things won't build with all implementations, we introduce a
brokenOn argument which influences the meta.targets list that is
created, but won't prevent the passthru attrs from being created to
ease debugging failures.
Change-Id: Icd6af345143593fac30ded10deabf31172e5d48a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3359
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
Both the deps and srcs arguments may now have special “filter sets” in
the lists they receive as arguments. When building, buildLisp checks if
such sets either have a attribute named like the current implementation
or a "default" attribute. If yes, the set is replaced by the respective
attribute's value. If no, the set is removed from the list without
replacement.
This can be used to add elements for (a) specific implementation(s):
{ sbcl = buildLisp.bundled "sb-posix"; }
{ sbcl = ./sbcl/optional-sbcl.lisp; }
or to switch between files for different implementations:
# If a implementation case is missing and no default set present,
# no file will be added. Compilation will likely fail as a result.
{
ecl = ./tf-ecl.lisp;
ccl = ./tf-ccl.lisp;
sbcl = ./tf-sbcl.lisp;
}
or to account for special behavior for a certain implementation:
{
ccl = ./ccl-quirk-impl.lisp
default = ./ansi-impl.lisp;
}
Change-Id: I082c3701d1f5063b92100bf336a83425471c269d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3321
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
By implementing a bundled function for an implementation, we can use a
custom one for a specific implementation. This is useful for
implementations like ECL where a require will be compiled as an
instruction rather than importing all new symbols into a dump, so using
the underlying static or shared object directly would be beneficial.
overrideLisp for bundled libraries now only allows overriding the name
and implementation arguments.
Change-Id: I9036b29157e8daa4d86ff87d603b044373711dbf
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3301
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
Concept is roughly:
* receive extra argument `implementation` that refers to the name of an
implementation or rather an attribute in an internal attribute set
telling buildLisp how to do certain build steps.
* We assume an implementation can execute lisp files as scripts and that
we can implement the following main tasks in lisp:
- Building a library (`genCompileLisp`)
- Building an executable (`genDumpLisp`)
- Loading a library dynamically (`genLoadLisp`)
Based on that we can implement:
- Running a test suite (`genTestLisp`)
- A REPL preloaded with a libraries and their dependencies (`lispWith`)
Additional attributes for implementing these parts genericly are
added as needed (`faslExt` and `runScript`).
* `genCompileLisp` no longer prints a shell script which concatenates
the individual FASLs. Instead it does the step previously done by the
shell script itself. In essence `genCompileLisp` now writes a lisp
script which compiles and installs the library to build.
This will allow us extra freedom for different implementations, e. g.
for ECL we'll want to build a object file archive additionally to fasl
files in order to be able to link proper executables.
* `genLoadLisp` and `genTestLisp` are almost generic (the former just
sometimes would need to use different file extensions), but we
integrate them into the implementation “API” to facilitate minor
tweaks we need to do like the `fasc` extension for ECL's native FASL
files.
Change-Id: I1b8ccc0063159638ec7af534e9a6b5384e750193
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3292
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
`makeOverriddable` doesn't work for bundled sbclWith as is because it
uses the `//` operator internally which doesn't work with the types
`bundled` and `sbclWith` accept as arguments (string and list
respectively).
What's more, `bundled` already uses `makeOverridable` and allows to
override the internal call to `library` via `overrideLisp`. For
`sbclWith` no such mechanism exists, but this seems to be no concern for
now: Using `overrideLisp` for this hasn't worked so far (and failed with
a _hideous_ evaluation error), so there doesn't seem to be any real
demand for this feature. Maybe a feature for another CL.
Change-Id: I0b2f34c00a2143cd66dd43a6b1b2880af997ee50
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3296
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
Using passthru and appending the attributes via `//` have the same
effect with a subtle difference: In the latter case re-evaluating
the derivation when using the underlying `mkDerivation`'s
`overrideAttrs` will delete all appended attributes. Using
passthru at least preserves the attributes although the self
reference to the derivation in `passthru.sbcl` will become
outdated (unless updated manually).
Change-Id: I8b85009f386b9375b86a23fd50c4ec8c6a9dea7f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3257
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: grfn <grfn@gws.fyi>
|
|
Machines on which LANG is misconfigured have trouble with SBCL loading
files that contain characters in certain encodings. This overrides
whichever local LANG (if any) is set.
Change-Id: Ic4341a01c4393e7f697de6cecc58dea4f2d85987
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2076
Tested-by: BuildkiteCI
Reviewed-by: glittershark <grfn@gws.fyi>
|
|
Expose an `sbcl` attribute on packages and programs, to allow for easier
development either with SLY or on a REPL.
Change-Id: Ide4d087a5223561e1fe192ef32dc593c54b5a20e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1834
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
Add support for explicitly specifying tests as part of a buildLisp
program or library.
Change-Id: I733213c1618f0fa60f645465560bce0522641efd
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1481
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
This was already happening for libraries, but not for programs - as a
result, programs built with libraries that contained unicode (eg
cl-unicode, uax-15, ...) would fail to build due to character encoding
issues when loading the FASLs.
Change-Id: I66149b585e85b213d0c026153140a1925536bd29
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1469
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
If you compiled dirA/test.lisp and dirB/test.lisp in the same library,
they'd both get written to /test.fasl and the second would overwrite the
first. Instead, use the whole store path (with / swapped for -) as the fasl
filename.
Change-Id: I4eb88b5d33757751e1f67e72ed328bd58079b1b9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/944
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
|
|
|
|
Makes it possible to add virtual dependencies on built-in libraries,
e.g. `buildLisp.bundled "sb-posix"`.
|
|
|
|
Adds an attribute on each Lisp derivation that specifies whether it is
a binary or not. This attribute is then filtered for in sbclWith.
|
|
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.
|
|
Adds a new 'native' parameter to the buildLisp functions in which
libraries can be passed in.
This does not yet work with CFFI packages.
|
|
This ensures that dependencies are loaded in the correct order in
larger dependency graphs.
|
|
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.
|
|
Dumps the executable image from SBCL to $out/bin/$name.
Image compression is disabled.
|
|
|
|
Adds `buildLisp.sbclWith` which creates an SBCL wrapper the contains
all the requested dependencies.
|
|
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.
|
|
This needs to be handled explicitly in the COMPILE-FILE form.
|
|
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).
|
