We've used a wayland-scanner = wayland.bin alias for ages, to make
packages clearer and allow them to be independently overridden.
Going the whole way into splitting them into separate packages is
useful because it means we can have different meta.platforms
attributes for libwayland and wayland-scanner.
There is no duplication in outputs between the two packages — they
don't install any files in common.
Since we're no longer pulling just one output into nativeBuildInputs
of packages using wayland-scanner, we can use upstream's
wayland-scanner.pc, which gets installed into the dev output, rather
than providing our own.
Otherwise, wayland-scanner would be picked up from the wayland in
buildInputs, which isn't cross-friendly and will stop working when we
split wayland-scanner into a separate package.
Otherwise, wayland-scanner would be picked up from the wayland in
buildInputs, which isn't cross-friendly and will stop working when we
split wayland-scanner into a separate package.
This may fix the build on Darwin (the `xvfb-run` package, which is
required only to run the testsuite, is Linux-only since #123097, and the
“proper solution” mentioned in that PR was not implemented). Apparently
someone cared about building `i3` on Darwin at the time of #6135.
The testsuite can run only on Linux, because it requires `xvfb-run`,
which is not available on non-Linux platforms; however, it should not be
limited just to `x86_64-linux`.
The conditional setting of `checkPhase` was introduced in #6135, because
at that time the `checkPhase` script referred to `${xdummy}`, and that
kind of reference would break evaluation if the specified package was
not available; the current version of the `checkPhase` script does not
refer to any package paths directly, therefore the condition is no
longer needed and can be removed.
The `i3-rounded` package is derived from `i3`, but uses some old fork of
`i3` which does not have the `318-i3-dmenu-desktop.t` testcase. Make
the code in `postPatch` check whether that testcase is actually present,
so that the build of `i3-rounded` does not fail.
Some tests in the i3 testsuite are silently skipped if the dependencies
required to run those tests are missing. The problematic dependencies
turned out to be `xdotool`, `xorg.setxkbmap`, `xorg.xrandr`, `which`
(the latter is used to verify the presence of some tools). Add those
dependencies to `buildInputs`, so that all tests would be run.
Ideally such missing dependencies should be detected as test failures,
but it's hard to implement, because missing tools result just in `skip`
marks in the test log, and there are some tests which are skipped for
other reasons (e.g., tests which were written before the expected
behavior is actually implemented in i3).
The `checkPhase` script was stale and needed to be rewritten for the new
version of i3 (paths are different now, and `complete-run.pl` now
invokes `xvfb-run` internally). The code to check the log file for
errors might be unneeded for the new version (`complete-run.pl` seems to
return a non-zero exit code correctly on errors), but is left to catch
any possible regressions in the test runner behavior.
Also the `318-i3-dmenu-desktop.t` testcase was failing, because that
testcase was creating a temporary Perl script intended to shadow the
real `i3-msg` executable, but the `#!/usr/bin/env perl` shebang in that
script did not work in the build environment; this problem was not
really obvious, because `system('i3-msg', $cmd)` silently continued to
search for the `i3-msg` executable further in `$PATH` and launched the
real binary instead of the replacement script. The problematic shebang
needed to be replaced manually, because `patchShebangs` handles only
real shebangs on the first line of each executable file.
This is done with the following bash script:
```
#!/usr/bin/env bash
process_line() {
local filename=${1%:}
if [[ $4 =~ \"(.*)\"\; ]]; then
local sha256="${BASH_REMATCH[1]}"
fi
[[ -z $sha256 ]] && return 0
local hash=$(nix hash to-sri --type sha256 $sha256)
echo "Processing: $filename"
echo " $sha256 => $hash"
sed -i "s|cargoSha256 = \"$sha256\"|cargoHash = \"$hash\"|"
$filename
}
# split output by line
grep -r 'cargoSha256 = ' . | while IFS= read -r line; do
# split them further by space
read -r -a parts <<< "$line"
process_line "${parts[@]}"
done
```
