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

[Marc Weber]

Rob: I have CC'ed you because you were faced the same issue we both
solved differently. I'd appreciate your view on this.

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.

Initially I wrote the patch for v8 (js engine). Meanwhile Rob packaged
it differently. So the whole patch has no use case at
the moment. So we can stop talking about it.

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

So it looks like this workaround should be documented at very least so
that it can be found faster. A comment in the scons expression is a nice
place IMHO.

Maybe Rob can talk about how long it took him to find that fix using
importenv=PATH.  I didn't knew about it. I still think that tools should
"just work".

The gcc wrapper is an example. Many compilations just work not because
configure scripts find libraries - but because NIX_CFLAGS_COMPILE and
NIX_LDFLAGS make most things work magically.

So the patch followed this spirit.

There is one use case for a unpatched scons version:
If you use nixpkgs on a non nixos system.  What do you do if you want to
build with native gcc and libraries?  Exactly: You remove
~/.nix-profile/bin from PATH. And then the patched behaviour is as
expected. That's the first and most simple thing you should try
(compared to reading scons build scripts, looking up documentation etc)

That's why I still think the patch is reasonable.

I wished Peter would have given a real use case - because I had one.
This makes me shut up and change my mind fastest.

You all remember the num-cores patch. That time I made the mistake
reverting my own patches because others told me to do so. I still regret
it. The result was 3 people implementing the same thing (Lluís Batlle,
me, Peter) - but the real issue was never solved. And that was:
"What is bad about this idea at all? Why do you fear it if its opt-in".

I'm not fighting for this particular patch. Its unimportant. I'm
fighting for the vision "let's serve real world use cases trying to
minimize the overall code base if reasonable" rather than abstract
things. I can't proof that the patch is better than following the
documentation. Adding a "INITIAL_DEFAULT_PATH" argument to the scons
derivation would "solve" it. But it would also add bloat.
The same kind of bloat pythonFull and ptyhonMinimal added.
Is there anybody prefering python without readline?

I do listen - and I am willing to change my mind. But I also want to
serve the KISS principle which is a good one (can't proof it).
If there is no strong reason for adding a parameter to scons (or
multiple scons reasons) it should be avoided for the same reason that
old xorg, openoffice versions etc are removed.

The more derivations the more complex everything will be. I hope you
agree that we don't want this unless there are strong reasons.

Marc Weber