stdenv.targetPlatform really shouldn't be used by software that
doesn't generate or manipulate binaries. I reviewed all uses of
targetPlatform outside of pkgs/development/compilers and pkgs/stdenv
and replaced those which weren't involved in something which fits
these criteria.
These versions don't build because their submodules use `git://` URLs,
which are no longer supported by GitHub.
I don't think there's a reasonable way to work around that since
`fetchgit` doesn't allow patching the source *before* fetching
submodules.
Currently, it is quite hard to override anything about dfhack (for
example, to add plugins at build time), because
1. it is not exposed anywhere, so you have to do something like
`dwarf-fortress.override (oldArgs: { dfhack = oldArgs.dfhack.override...; })`
2. the final `dfhack` derivation is a `buildEnv`, so `overrideAttrs`
doesn't work as expected.
This fixes 1 by adding `dfhack` to the wrapper's `passthru`, and 2 by
moving `twbt.lib` (which is the only reason for the dfhack `buildEnv`)
into the wrapper.
Also adds an `extraPackages` argument to the wrapper, and copies `*.init`
files from the env to the DF directory so that we can easily add a
`dfhack.init`.
With these changes, I was able to build dfhack with the dfplex plugin.
Since the setting DCMAKE_SKIP_BUILD_RPATH was disabled, we can now run
the checkPhase of cmake derivations without having to tweak the
LD_LIBRARY_PATH anymore.
Otherwise you get an error upon starting the game:
```
Plugin twbt was not built for this version of DFHack.
Plugin: 0.47.05-beta1, DFHack: 0.47.05-r1
```
The original mifki TWBT hasn't been updated since April 2019, while
thurin's fork has added support for dfhack 0.47.04-r2. Thus, switch to
thurin's fork when Dwarf Fortress 0.47.04 is used (and ever-so-slightly
special case the url attribute).
dfhack expects an unversioned libruby.so to be present in the hack
subdirectory for ruby plugins to function. The glob is necessary,
because the ruby package's library names are formatted as
ruby-${version}.so for whatever reason. The glob makes it possible for
ruby to update without manual intervention being needed here.
As of
56e43a0dde,
dfhack gets its goodies from the directory above the Dwarf_Fortress
executable, which leads to stock Dwarf Fortress and not the built
environment where all the dfhack resources are symlinked to (typically
~/.local/share/df_linux). This causes errors like `tweak is not a
recognized command` to be reported and dfhack to lose some of its
functionality.
