LDMud is a game engine for text based multi-user dungeon games (MUDs),
in the "LP" heritage. In essence it is a virtual machine that allows
developers to implement MUD games ("mudlibs" in LD parlance) using the
LPC programming language.
In the project's own words:
> This is 'LDMud', a gamedriver for LPMuds. (LPC compiler, interpreter
> and runtime environment.)
>
> LDMud started as a project to clean up and modernize Amylaar's LPMud
> gamedriver. Primary goals are full documentation, a commented source
> body and out-of-the-box support for the major mudlibs, of which the
> commented source body has been pretty much completed. During the course
> of work a lot of bug fixes and improvements found their way into the
> driver - much more than originally expected, and definitely enough to
> make LDMud a driver in its own right.
For nixpkgs the new LDMud addition is largely a standard derivation for
an autoreconf/automake based project. Some small tweaks are required to
get everything lined up between the Nix environment and the LDMud build
system.
The new LDMud derivation is placed in `pkgs/games/ldmud/` alongside
other MUD-related projects in the games category (e.g. `mudlet`,
`blightmud`).
LD offers a variety of optional features, some of which require heavier
dependencies (e.g. MySQL/Postgres client libraries). To support both
a minimal default build equal to what one gets using the upstream build
with no customization, and to also support a more useful fully featured
build, the LDMud derivation is added to `all-packages.nix` twice:
1. the `ldmud` attribute builds the minimal default configuration (just
the optional gcrypt and pcre options enabled, matching upstream).
2. the `ldmud-full` attribute builds LDMud with all of the optional
features enabled (database support, Python support, TLS support,
etc).
Passing `-l$NIX_BUILD_CORES` improperly limits the overall system load.
For a build machine which is configured to run `$B` builds where each
build gets `total cores / B` cores (`$C`), passing `-l $C` to make will
improperly limit the load to `$C` instead of `$B * $C`.
This effect becomes quite pronounced on machines with 80 cores, with
40 simultaneous builds and a cores limit of 2. On a machine with this
configuration, Nix will run 40 builds and make will limit the overall
system load to approximately 2. A build machine with this many cores
can happily run with a load approaching 80.
A non-solution is to oversubscribe the machine, by picking a larger
`$C`. However, there is no way to divide the number of cores in a way
which fairly subdivides the available cores when `$B` is greater than
1.
There has been exploration of passing a jobserver in to the sandbox,
or sharing a jobserver between all the builds. This is one option, but
relatively complicated and only supports make. Lots of other software
uses its own implementation of `-j` and doesn't support either `-l` or
the Make jobserver.
For the case of an interactive user machine, the user should limit
overall system load using `$B`, `$C`, and optionally systemd's
cpu/network/io limiting features.
Making this change should significantly improve the utilization of our
build farm, and improve the throughput of Hydra.
`SDL2_mixer` is a a popular game dependency. Split it's `dev` output to
separate store path to reduce runtime closure size.
While at it amend a few games's include paths.
`opusfile` is a a popular game dependency via `SDL2_mixer`. Split it's
`dev` output to separate store path to reduce runtime closure size.
While at it amend games's include paths.
