Introduce a `skawarePackages.buildPackage` function that contains the
common setup, removing a lot of duplication.
In particular, we require that the build directory has to be empty
after the `fixupPhase`, to make sure every relevant file is moved to
the outputs.
A next step would be to deduplicate the `configureFlags` attributes
and only require a `skawareInputs` field.
The configure scripts have been changed so that `--build` is now the
way to specify (non-cross compiling) build target, which is necessary
on darwin for binary compatibility across darwin versions.
execline: 2.1.4.5 -> 2.2.0.0
s6-dns: 2.0.0.7 -> 2.1.0.0
s6-linux-utils: 2.0.2.3 -> 2.2.0.0
s6-networking: 2.1.0.4 -> 2.2.1.0
s6-portable-utils: 2.1.0.0 -> 2.1.0.0 (no version change)
s6-rc: 0.0.2.1 -> 0.1.0.0
s6: 2.2.4.3 -> 2.4.0.0
skalibs: 2.3.9.0 -> 2.4.0.1
Also use new --enable-absolute-paths configure arg to correctly set
paths to runtime executables to point within the nix store rather than
relying on PATH resolution.
In line with the Nixpkgs manual.
A mechanical change, done with this command:
find pkgs -name "*.nix" | \
while read f; do \
sed -e 's/description\s*=\s*"\([a-z]\)/description = "\u\1/' -i "$f"; \
done
I manually skipped some:
* Descriptions starting with an abbreviation, a user name or package name
* Frequently generated expressions (haskell-packages.nix)
skalibs:
execline:
s6-dns:
s6-networking:
s6-portable-utils:
s6-rc:
s6:
The above software uses the target triplet from `cc -dumpmachine` as a
binary compatibility check. However, on darwin, the output includes the
darwin version number, which leads to build failures against a binary
skalibs package built a different version of darwin than the current
system.
Explicitly setting target ensures code can be compiled against a skalibs
binary built on a different version of darwin.
See http://www.skarnet.org/cgi-bin/archive.cgi?1:mss:623:heiodchokfjdkonfhdph
