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
