I want to build TR1X (an OSS Tomb Raider engine) as requested but the build process is apparently entirely built around Docker.
This is as far as I got with my experiments, failing because the running Docker daemon is obviously not being exposed to the build environment:
...
@nix { "action": "setPhase", "phase": "buildPhase" }
Running phase: buildPhase
build flags: SHELL=/nix/store/cjbyb45nxiqidj95c4k1mh65azn1x896-bash-5.2-p21/bin/bash
mkdir -p build
docker run --rm --user 1000:100 --entrypoint /app/docker/game-win/entrypoint.sh -e TARGET="deb>
docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daem>
See 'docker run --help'.
make: *** [Makefile:28: debug] Error 125
The immediate “solution” that comes to mind is exposing Docker to the build env somehow but I think it won’t work anyway because of the non-deterministic nature of Docker (the docker container the build process ends up with may be different even if the source code doesn’t change).
On the other hand, reverse-engineering the build process and rewriting it in an immutable fashion seems like an overkill.
Do we have a solution for this? I couldn’t find anything anywhere - there’s too much noise with Nix and Docker in the search results
To me it looks more like Docker is a runtime dependency.
However only to make it easier to run.
I don’t know of an easy conversion bit at least the Dockerfile lists most dependencies explicitly.
Edit: Correction, Docker is just used for building but the above still applies for building the package.
Unfortunately there are multiple and with relatively high number of layers. It is definitely possible to “convert” the Dockerfiles to a more nix-friendly setup but that would mean a relatively high “support and maintenance” cost on the packager side which I’m not sure is worth it.
Another option might be binary distribution - upstream provides pre-compiled tarball but preliminary checks show weird things (weird to me at least):
user@laptop /tmp/t % ./TR1X
Could not start dynamically linked executable: ./TR1X
NixOS cannot run dynamically linked executables intended for generic
linux environments out of the box. For more information, see:
https://nix.dev/permalink/stub-ld
127 user@laptop /tmp/t % file TR1X
TR1X: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), statically linked, no section header
user@laptop /tmp/t % patchelf TR1X
patchelf: no section headers. The input file is probably a statically linked, self-decompressing binary
I didn’t make any deeper research beyond this quick try yet.
I’m not sure you even need upx because you probably don’t need to package the binary for Nixpkgs.
The output of the binary basically already tells you everything you need to know for running the binary. However I wouldn’t use that solution to package it when you have the source available.
