RFR: JDK-8034199 Add 'reconfigure' target for re-creating a configuration
mike.duigou at oracle.com
Wed Feb 12 17:58:50 UTC 2014
On Feb 12 2014, at 09:31 , Henry Jen <henry.jen at oracle.com> wrote:
> On 02/12/2014 07:11 AM, Magnus Ihse Bursie wrote:
>> 12 feb 2014 kl. 14:55 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>>> First I was disappointed to lose the configure-arguments file, which I sometimes look in to see how configure was run, but I can just as well look in spec.gmk.
>> Yes, that was my own reaction too. :-) "Hey, I can't remove that". :) I'm not even sure why I initially didn't think of putting it in the spec.gmk instead if a separate file...
> Usually I checked at config.log, I didn't even know this file exist.
ditto. I look at config.log or config.status.
>>> Have you tried running with complex arguments, like --with-extra-cflags="-flag1 -flag2"?
>> No. It will probably fail. :( Maybe we can detect this and warn/refuse to run, but I don't even want to start thinking how we could support that in the reconfigure target. It's probably not worth it.
This worries me. If someone does use complicated options that would fail on re-run perhaps it's best to fail immediately rather than leave a mysterious (possibly silent) failure for some later point. Either fully support it or don't support it at all.
Imagine --with-extra-cflags="-flag1 -q"
If the -q gets turned into a configure option on reconfigure what havoc might this wreak?
> Dealing the quote is not fun, I agree it's probably not worth it.
More information about the build-dev