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

[7c6f434c at mail.ru]

> > Using distinct SCons builds for every scons-built package make it a
> > huge source of headache.
>
>it appears that you have misunderstood the suggested solution. The
>ability to hard-code a user-supplied search path into SCons is purely
>optional. There is no place in nixpkgs that depends on this feature. In
>fact, nixpkgs expressions don't depend on SCons' default search path at
>all! Consequently, there is not going to be a distinct SCons build for
>every SCons-built package. Your worries are unfounded.

There are many places in nixpkgs, though, that rely on complex time-consuming
workarounds. And if the only relatively simple way to use scons is building a
custom scons binary each time - this is what will happen. 

The original patch was created because current scons behaviour is simply
inconvenient for packaging scons-dependent software. It looks like the 
solution is replaced with ability to make custom scons - and this is what
will get used as a solution. 

Eelco's solution includes hard-coding the stdenv used to build scons into 
scons - and that leads to behaviour differing from every other build tool
we have.