Builds currently fail with `ar` trying to operate on what are clearly
two paths concatenated together. It stems from a backward-incompatible
change in Make:
> Previously appending using '+=' to an empty variable would result in
> a value starting with a space. Now the initial space is only added
> if the variable already contains some value. Similarly, appending an
> empty string does not add a trailing space.
This issue was first reported on the MAME repository proper
(https://github.com/mamedev/mame/issues/6248), and affects libretro's
2016 snapshot as well. A fix that is reported to work with previous
versions of Make was upstreamed to:
- GENie, the build system: https://github.com/bkaradzic/GENie/pull/493
- MAME: https://github.com/mamedev/mame/pull/6262
- libretro: https://github.com/libretro/mame2016-libretro/pull/47
The fetched patch comes from the last of these.
After making `ffmpeg` point to the latest `ffmpeg_4`, all packages that
used `ffmpeg` without requiring a specific version now use ffmpeg_3
explicitly so they shouldn't change.
This should fix the regression found in
https://hydra.nixos.org/eval/1577308#tabs-now-fail. The libretro
scripts use “osx” as the identifier for macOS, and “unix” seems to
mean linux.
If anyone could help out by confirming this works. I don’t currently
have access to a macOS machine.
- Avoid using overrides unless necessary
- Set platform and ARCH by default
- Don’t set dontConfigure unless absolutely necessary
- Use preBuild instead of overriding entire configurePhase
Upstream has broken git history [1], so the current version cannot be
fetched. The required patches have been upstreamed [2], and we hope
that upstream will be more careful with their git history.
The previous commit can still be viewed on github [3], but is not the
ancestor of any fetchable ref.
[1] https://github.com/libretro/snes9x/issues/199
[2] https://github.com/snes9xgit/snes9x/pull/588
[3] 29b78df8c9
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
