> > 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. _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
