| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
In newer versions of libfmod, there are two calls to system(), which
cause the setup hook to fail, since it only expects one such call.
Fortunately, we don't want libfmod to execute *any* external commands,
so fixing this is rather easy by just making *all* calls to system() a
no-op.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
| |
The name "hook" is a not very good derivation name to distinguish it
from other hooks, so let's actually name them.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to @layus for pointing out that there is at least one other game
(Epistory) which has the same FMOD issue as Bastion has.
So I decided to move this into a setup hook that automatically discovers
whether it's the affected FMOD version and NOPs out the calls to
system().
In summary: If another game is affected, all that's needed now is to add
fixFmodHook to nativeBuildInputs.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @layus
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should make all the extra unpackCmd attributes for the GOG games
superfluous and make the expression way less convoluted, especially the
games based on Unity3D.
Right now however, the gogUnpackHook is added to buildGame, which is
used for all games, not only for the GOG ones. While it doesn't really
hurt or affect non-GOG games, it's still part of the build closure so we
might want to apply this to GOG only at some day.
For that, we need to restructure our whole packaging layout, because we
want to have a way to override buildGame only for a certain namespace
but without introducing too much churn or duplicating things.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @layus
|
| |
|
|
|
|
|
|
|
| |
This is really not game-specific, so let's put it at the top-level and
also make sure we substitute all the commands we're using there, even
though a few of them are in PATH of stdenv so that it will always work
even when the programs available in stdenv should change someday.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
So far we only matched the file name of the dependency but not its
architecture, so if for example there is one shared object for
i686-linux and another one with the same name but for x86_64-linux,
chances are that the wrong architecture is chosen.
Now we're checking the architecture of the shared object file and only
pick it, if it matches the architecture of the file to patchelf.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
| |
This makes sure that ldd doesn't print warnings like if the file isn't
executable and also makes the status messages a bit more clear.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The semantics of adding env hooks has changed in
NixOS/nixpkgs@7f3ca3e21a22fd3101b40cadb86899542dec2e35 so that it's now
broken up into several hook variables (envBuildBuildHook,
envBuildHostHook, envBuildTargetHook, envHostHostHook, envHostTargetHook
and envTargetTargetHook).
Fortunately commit NixOS/nixpkgs@a036473a0a0c6100fce316e1444fc33ec6674b
adds a helper function (addEnvHooks) to deal this without referencing
those hook variables directly and rather just providing an offset.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far creating the sandbox has been a setup hook, however it's a bit
ugly how we gathered the needed paths for the chroot file system by
recursively searching for store paths.
While I'd like to have the sandbox being built within the main
derivation, it really isn't very practical when the build takes longer
than 10 minutes.
With this implementation however the sandbox builds really fast and we
can also modify the sandbox without needing to rebuild a particular
game.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is basically to make sure various games can't write to whatever
they want in the file system, so it's not a complete sandboxing
solution.
Currently there's a drawback in that we can't easily determine the
runtime dependencies while building a particular game, so we need to
recursively dig through all referenced store paths to look them up.
A better solution for this would be to gather the build time reference
graph prior to building so that we can limit searching for these
references within only the actual build outputs instead of churning
through all inputs.
In addition to that, we currently mount the namespaced root file system
on top of /tmp, which makes the real /tmp unavailable to us. While in
theory this shouldn't be a problem, it actually turns out it is indeed a
problem if the application wants to connect to the X server socket,
which is at something like /tmp/.X11-unix/X0 for display :0.
Apart from these drawbacks we have a working solution for simple
applications (not games, because they usually require X), which now get
its own chroot with only the paths accessible that are strictly
necessary.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
| |
This allows us to add libraries to the RPATH despite being required by
the respective game. By default there is only PulseAudio at the moment.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
The main functionality for this function is to gather missing
dependencies in ELF executables and shared libraries and using patchelf
to set the right RPATH.
All of the dependencies are searched based on what we have in one of the
buildInputs variables, so all we need to do is list them in there.
One thing that's still left to solve is adding libraries to the RPATH
which are only required at runtime. An example for this would be the
pulseaudio library.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
