Help making a flake (for Geant4 (particle physics framework) examples)

jacg · March 2, 2021, 4:52pm

TLDR

Can you help me make a semi-decent flake for running examples of the Geant4 toolkit for interaction of particles with matter?

Here is what I have so far: GitHub - jacg/nain4: An API that makes it easier to write Geant4 application code..

Caveats

This is a Nix flake, therefore it won’t work without a flakes-enabled (i.e. unstable) Nix.
I don’t know how to get Geant4 to work in Nix on MacOS, so this only works on Linux.

Something to try, that should work

nix build github:jacg/g4-examples-flake --out-link /tmp/g4b1
tree /tmp/g4b1 # (assuming you have `tree`)
nix develop
cd $B1_MACRO_DIR
/tmp/g4b1/bin/exampleB1 # Tries to use OpenGL so YMMV

Things that don’t work

The executable absolutely needs to know the location of the G4 datasets (and probably some other crucial info). This is done by sourcing ${geant4}/bin/geant4.sh, which seems to happen automatically in nix develop (I’m not sure how), but I don’t know how to make that happen for nix shell or nix run.
G4 programs are supposed to be executed from the directory containing the *.mac files which control the run. In this flake, that’s B1_MACRO_DIR. I don’t know how to get nix shell and nix run to cd B1_MACRO_DIR.

Consequently nix shell and nix run don’t do anything sensible. The latter does demonstrate the need to know the aforementioned G4 data directories, by crashing with the error

G4ENSDFSTATEDATA environment variable must be set
*** Fatal Exception *** core dump ***

.

Questions

Can you spot anything obviously stupid/superstitious/misguided in what I have so far?
I never remember/understand the distinction between buildInputs and nativeBuildInputs. Can you offer any wisdom?
Is there any documentation for defaultApp anywhere? From examples I infer that { type = "app"; program = "<an executable>"; } works, but can you do anything else with it? What types are there besides "app"? [Answered below; TLDR: nope, that’s it!]
Can you suggest how to make progress on getting nix shell and nix run?

jacg · March 3, 2021, 1:31pm

This seems to be it: https://github.com/NixOS/nix/blob/1b578255245e2e1347059ad7d9171cf822c723a8/src/nix/run.md#apps

At present, the answer seems to be ‘no’.

At present, the answer seems to be ‘none at all’.

jtojnar · March 3, 2021, 1:53pm

github.com

jtojnar/nixpkgs-hammering/blob/407fb261a1a572b0292b3613bc5af9dde503f87e/explanations/build-tools-in-build-inputs.md

The following packages are primarily build tools so they likely go to `nativeBuildInputs`, not `buildInputs`:

- `cmake`
- `meson`
- `ninja`
- `pkg-config`

The distinction primarily matters when [cross-compiling](https://nixos.org/nixpkgs/manual/#chap-cross) a package for a different architecture than the one the build runs on – if you want to run a program during a package’s build, its _host_ (runtime) architecture needs to match the package’s _build_ architecture, or the operating system might not be able to execute it.

Dependencies listed in `nativeBuildInputs` will ensure precisely that, while those in `buildInputs` will have the same _host_ platform as the built package.

Note: In most derivations, when not cross-compiling, the programs listed in `buildInputs` will end up in [`PATH`](https://github.com/NixOS/nixpkgs/blob/390d38400aa7a425abef6e20c6773e2717b2fda1/pkgs/stdenv/generic/setup.sh#L486-L488) environment variable for build too. But you can force the distinction by setting `strictDeps = true;`; and [`python3.pkgs.buildPythonPackage`](https://github.com/NixOS/nixpkgs/blob/01b0290516db18ebfda5eee3b830fe5c0cebcf4b/pkgs/development/interpreters/python/mk-python-derivation.nix#L50-L51) and `rustPlatform.buildRustPackage` already enable that option by default.

## Exceptions

- When building an environment for an IDE, you will likely want to be able to run the build tools at runtime so they should go to `buildInputs` (possibly to both).

jacg · March 3, 2021, 6:27pm

IIUC:

The old nix-shell served a dual purpose and the new Nix caters for these via two separate mechanisms: nix shell and nix develop.
In the old Nix, shellHook was executed by nix-shell.

What are the interactions between shellHook and nix shell/nix develop?

In my flake, nix develop shows signs of having executed source ${pkgs.geant4}/nix-support/setup-hook but I have no idea how or why; various experiments seem to suggest that it has nothing to do with shellHook.

The effects of source ${pkgs.geant4}/nix-support/setup-hook are absent from (but needed in) nix shell: how should I go about providing them?

jacg · March 4, 2021, 1:41pm

Maybe this should be done with wrapProgram? But I don’t see how to automate extraction of the settings provided by ${geant4}/nix-support/setup-hook into a form that can be consumed by wrapProgram.

ilkecan · October 20, 2021, 5:49pm

Yes.

Since nix develop is the successor of nix-shell; while not documented, it has the same behaviour regarding shellHook.

nix-shell and nix develop are used to create the build environment of a derivation. shellHook can be used to perform initialisation specific to the interactive build environment. So it is only useful for nix-shell and nix develop.

nix shell, similar to nix-shell -p, is used to create a shell environment where the specified packages are already built and ready to be used. So shellHook variable isn’t used with nix shell and nix-shell -p.