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

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Tue Jan 28 22:23:33 UTC 2014


On 2014-01-28 22:43, Mike Duigou wrote:
> I really prefer the enhanced semantics!
Thanks!
>
> - 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.
There is already a way to force re-generation: "bash 
common/autoconf/autogen.sh". I think that's good enough, but it should 
probably be better documented (like more details of the build system; 
probably on a wiki somewhere in Dreamland where people will actually go 
and read the docs ;-)).

> - BASIC_PATH_PROGS(READELF, [readelf greadelf]) seems reversed from the normal case where "g" version of a tool is preferred if available.
Ok, I fix that. I noted that too but didn't change it. But I agree that 
preferring the "g" version seems reasonable. (Given that we trust GNU 
tools more than anything else :))

> - 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?

I'd like to not dwelve too much into that area now. Figuring out exactly 
how the tools are used and if they really are optional or required is an 
effort of digging into all makefiles in the product. Unfortunately, I'm 
not 100% sure the current classification in the configure script is 
correct, but it seems to work most of the time. :) Were there any 
specific tools you were thinking of? (Most of the "required on some 
platform" tools are like solaris or macosx specific tools that do not 
exist, and/or are not needed or used on other platforms. The use of 
these tools in the Makefiles are guarded with ifdefs.)

/Magnus



More information about the build-dev mailing list