RFR: JDK-8031759 Configure should handle overrides of tools better

[Magnus Ihse Bursie]

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