On 2014-01-27 09:26, Dave Pointon wrote:
Hi Magnus ,
On Wed, 2014-01-22 at 16:29 +0100, Magnus Ihse Bursie wrote:
Sure, I forgot about the greadlink addition. I'll fix that.
Also, your comment got me wondering if this is the wrong solution after all. We have
tried hard to stay clear of letting environment variables affect the build, since they
are "invisible", impossible to check and creates hard to debug problems. And
now I'm letting in a hoard. :-/ Overriding tools is one thing, but I'd really prefer to
do it on the configure command line.
I'll see if I can tweak configure to only accept overrides as command line
arguments, and emit warnings or errors if an incorrect override is attempted.
Stay tuned for a new webrev.
/Magnus
<snip>
I'd be interested to learn of the context surrounding your assertions
WRT environment variables, specifically regarding their invisibility and
impossibility to check.
Several things, but they all are related to the same core issue.
1) For options on the command line, we can check for mistypes. If you
type "CATT=miawu configure" this can never be caught, but "configure
CATT=miawu" can.
2) Since environment options (per definition) is shared with the
environment it is not directed at configure. So you have another program
you often run that requires you to set CAT=foo. Now that affects
configure, too. Probably unexpectedly.
3) Having a complete reproducer is a pain, since it requires you to dump
the complete environment. And that will drag along tons of non-relevant,
potentially private, information. Have you checked your environment?
Mine is 85 entries long, on a cleanly installed machine with no
customizations. A typical configure command line does not have 85 arguments.
/Magnus
