I really prefer the enhanced semantics!
- another non-autoconf option to configure to force regeneration of
generated-configure would be nice. ("--force-autogen" perhaps?) Applying
patches (such as this one) I sometimes find that the timestamp check gets
confused and fails to regen. "touch common/autoconf/basics.m4" is my current
workaround.
- BASIC_PATH_PROGS(READELF, [readelf greadelf]) seems reversed from the normal
case where "g" version of a tool is preferred if available.
- there are tools which are conditionally required on specific platforms but a
few which are "# These are not required on all platforms". Should these perhaps
be put into conditional blocks and required on the platforms they are needed or
are they truly optional?
Otherwise looks good!
Mike
On Jan 28 2014, at 05:52 , Magnus Ihse Bursie <[email protected]>
wrote:
> On 2014-01-22 16:29, 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.
>
> Okay, so here's the revised version. What's new this time:
>
> * Overriding of tools is only supported on the command line. If user types
> e.g. "CAT=miaow configure", this will result in a warning (and cat being
> detected normally). "configure CAT=/bin/woof", otoh, will use the provided
> value instead of searching. (And "configure CAT=missing" will search the
> $PATH for a binary named "missing", and use that if found).
>
> * If the user specifies an override that does not match a real tool, e.g.
> "configure NOSUCHTOOL=broken", then the configure script will report this as
> an incorrect argument error.
>
> * Variables that can be overrided in this manner are published in the help,
> using AC_ARG_VAR (thanks Mike for the idea!)
>
> * I have added the greadlink alternative for READLINK from Mike's patch.
>
> * The tool setup code is considerably rewritten, to collect all actual work
> in a "workhorse" function, with thin wrappers providing the external API.
> This enabled removing of some unneccessary code duplication.
>
> WebRev:
> http://cr.openjdk.java.net/~ihse/JDK-8031759-better-overriding-of-tools-in-configure/webrev.03
>
> /Magnus
