I don't think there's any situation in which an unwrapped execlineb is
useful -- if you want to use different versions of the execlineb tool
it'll still prefer ones in PATH. At the same time, implementing the
wrapper in this way, as a series of two derivations, meant that we
didn't get stdenv goodness for the wrapper. This meant that, for
example, the wrapper was not stripped, and so execline ended up with
runtime dependencies on gcc and the Linux headers. I don't want to
have to reimplement this sort of stuff when it's already in stdenv,
and so it makes much more sense to create the wrapper in the
mkDerivation call, where all of stdenv's normal magic will find it.
Instead of using execlineb to define the execlineb wrapper, we replace
it by a little C wrapper.
This is mainly done because on non-Linux systems (i.e. mainly macOS),
it is impossible for a shebang interpreter to be itself a shebang
script.
It is, however, perfectly fine to have a chain that goes
shebang -> ELF -> shebang -> ELF -> …
Co-Authored-By: Laurent Bercot <ska-skaware@skarnet.org>
Introduces the `execlineb-with-builtins` flag, which when
true (default) will add all execline builtins to the PATH of
`execlineb`.
This is usually what users expect.
If the flag is set to `false`, the unpatched execline derivation is
returned instead.
Using wrapProgram adds a call to `bash` around every call
of `execline`, which clearly misses the basic idea behind
`execline` in the first place …
This reverts commit b64d25c447.
The execlineb program is the launcher (and lexer) of execline scripts.
So it makes a lot of sense to have all the small tools in scope by
default.
We append to the end of PATH so that they can be easily overwritten by
the user.
Co-authored-by: Alyssa Ross <hi@alyssa.is>
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.
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
The website gives no indication that version 4.x is required to build
this package, and even it if were, then there should be an override in
all-packages.nix instead of referring to the 'gnumake40' attribute
directly in this expression.
New build system using configure script and GNU Make 4.0, and new
releases of the following using the new build system:
execline 2.0.0.0
s6 2.0.0.0
s6-dns 2.0.0.0
s6-linux-utils 2.0.0.0
s6-networking 2.0.0.0
s6-portable-utils 2.0.0.0
skalibs 2.0.0.0
