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>