>it appears that you have misunderstood how that solution would work. You >seem to assume that SCons would be passed a search path every time it is >run. In fact, however, SCons would be passed that search path at the time >SCons itself is being built. Those paths are subsequently hard-coded into >the SCons binary to ensure that they are set every time SCons is run. This >solution guarantees deterministic behavior regardless of whether SCons is >being run from Nix or from any other context. In particular, you'd be free >to configure SCons to search for tools in "$HOME/.nix-profile/bin", which is >what you suggested. > >In other words, the solution Eelco proposed can trivially emulate yours, but >your suggestion cannot emulate Eelco's. Consequently, the approach suggested >above seems to be strictly more powerful, and thus preferable.
Actually, it will be strictly more powerful as debugging supplier. Its ability to use hard-coded gcc when used with non-default stdenv (a situation which occurs quite a few times in nixpkgs), its potential to incentivize considerably different SCons binaries in build environments and in user environments, its incentivizing using distinct SCons builds for every scons-built package make it a huge source of headache. Having five builds of SCons that differ only in search path on any system where package development is done seems to be quite suboptimal. We treat different users of NixOS system as if they were users of different boxes with only kernel and system services enforced to be the same. If we readjust SCons assumptions to this fact, the path fixing gives more drawbacks than benefits; and when we want a really deterministic environment, we do have a real tool for it. _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
