[Nix-dev] Re: [PATCH 1/2] t/scons

[7c6f434c at mail.ru]

>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.