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

[Kevin Quick]

I'm a little late to this discussion, but as an SCons user I would like to vote in support in Marc's patch (mostly, see below).

On Wed, 22 Dec 2010 13:34:09 -0700, Marc Weber <marco-oweber at gmx.de> wrote:
> Excerpts from Peter Simons's message of Wed Dec 22 18:35:42 +0100 2010:
>> ideally, that exact list of paths would be passed to the expression as a
>> parameter, so that these settings can be overridden easily. That would allow
>> us to instantiate many different variants of scons that use different tools
>> by default.

This works if you are running scons in a nix derivation, but not if you are simply running it in a dev tree for a local project that does not have a nix derivation.

> He solved it this way:
>   scons snapshot=on importenv=PATH arch=${arch}

Ironically, this is (IMHO) what Knight (the SCons designer) was trying to avoid: having user environment changes impact a build so that the same build done by two different people would have two different results.  The idea was that SCons would only use the set of "standard system-installed tools" as the default.  Any adjustments were made explicitly within the SConstruct file so that *all* builds would have those adjustments, thereby resulting in repeatability and reliability of SCons-based builds.  This is what I understood the documentation and Knight to intend.

[These claims are just my opinion.  As partial credentials for making these claims I'll note that I was a contributor to SCons itself for a while.  Although I didn't ever ask Knight about this specific issue I make the above assertions based on what I do know of SCons and of course, what I want it to do.  :-) Again, these claims are just my opinion and I cannot actually speak for Knight or the SCons project, although I am speaking as an SCons user recently bitten by this issue.]

The above "importenv=PATH" works around the problem but clearly violates this original intention.  Even more ironically, the per-user environment flexibility of NixOS is juxtaposed against the "system standard" intent of SCons precisely because there is no system-wide standard for NixOS.  :-)

I would like to suggest that Eelco's proposal of passing explicit tools to form the path for a derivation using SCons would cause the appropriate path-env override to SCons, but that a plain cmdline invocation of SCons should default to including $HOME/.nix-profile/bin (essentially Marc's patch but slightly different).

   1) The latter part is a slight modification on Marc's original patch, but provides the best interpretation of "standard system-installed tools" in light of the ironies noted above.

   2) The former allows explicit dependency management (via an updated patch to use something like the proposed NIXOS_SCONS_BIN) for Nix derivation-based builds.

   3) This proposal fits the principle of least surprise.  The surprise being that an SCons-based dev tree which works in almost *all* other environments (including Windows, MacOS, etc.) will not "just work" on NixOS.  This might be a small (but annoying) issue for the developer who originated the scons usage (although it cost me more investigation time than I care to admit or repeat), but imagine the case for a developer simply wishing to "try out" building a source tree they didn't develop.  This "surprise" is likely a show-stopper for that activity, especially if they aren't familiar with SCons.

   4) Peter, my arguments above address the documentation issue, but I'd like to also make one more argument:  the SCons Tools infrastructure includes a lot of automatic environment probing and work to automatically locate tools that are available--albeit on the "standard" PATH--to find gcc or mingw or icc, etc. and many other variations on specific tools.  I believe this supports my assertion above that SCons was intended to work without surprises or additional work in a standard environment.


-- 
-KQ