This substition produces a nixos-build error, because the target string
was removed in commit 323891ea5964d54aba2d272ddddbf748ce353176 in 2018.
Remove the substition from the `postPatch` phase of `sbcl/common.nix`.
This substitution produces a nix-build warning, because the target
string was removed in commit 7b225df9a492977b8fff0948ce93c5ab31766f64
in 2016.
Remove the substition from the `postPatch` phase in `sbcl/common.nix`.
- Remove some debugging output at the start of the `patchPhase` section,
which appears to have outlived its value.
- Rename `patchPhase` to `postPatch`, to avoid preventing people adding
patches via the `patches` variable.
- Add `preBuild` and `postBuild` run-hooks to the `buildPhase` section.
- Add `preInstall` and `postInstall` run-hooks to the `installPhase`
section.
The sbcl version specific nix expressions were an exact copy of each
other with the version and hash swapped out, leading to unnecessary code
duplication. This has been resolved by moving the common expression to
common.nix and only tracking version and hash in the version specific
expressions.
Since the expression is unchanged, this should cause 0 rebuilds.
Programs which generate and compile a lot of code at runtime (such as
programming language interpreters like ACL2) are not suited for running on SBCL
executables built with the "immobile space" feature, as explained by Douglas
Katzman in this mail thread:
https://sourceforge.net/p/sbcl/mailman/message/36007057/
In this commit, I add an optional flag to the SBCL package allowing you to
disable the "immobile space" features.
I also migrated away from specifying enabled/disabled features in a
`customize-target-features.lisp` file and towards supplying them as command line
arguments to `make.sh`, as has been recommended by the installation instructions
since 2012 or so.
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
