Code Review Request: Simple new build system fix

[Erik Joelsson]

On 2013-03-13 15:01, Andrew Hughes wrote:
> ----- Original Message -----
>> Hello,
>>
>> I created a bug for you:
>>
>> 8009988: build-infra: Fix configure output for zip debuginfo check
>>
>> As David says, we haven't decided on 2.67, but I would guess that a
>> majority of the commits have been with that version. This change is a
>> first step towards enforcing a specific version and I'm ok with that.
> Yes, I've been out of the loop a bit on this new build system.
> When I saw the huge diff my first attempt generated, I just assumed
> I should be using the same version that had been used previously.
>
>> The actual fix looks good to. You will still need a JDK reviewer to
>> ok
>> it. Also, please notify me when you push this so that the closed
>> version
>> of the configure script may also be regenerated.
>>
> Ok, no problem.  I await a review from someone like David or Kelly.
>
> Is there a preferred tree to push to?  I spotted this when just trying
> to build so it's against jdk8 at the moment (which I obviously can't push
> to).  Perhaps build?
>
Please use jdk8/build.

/Erik
>> /Erik
>>
>> On 2013-03-13 13:18, Andrew Hughes wrote:
>>> I've finally found time to look at the new build system (well,
>>> there seems to no longer be any choice ;)
>>> and so thought I start out with a simple fix.
>>>
>>> http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/
>>>
>>> At the moment, if disable-zip-debug-info is not specified, the
>>> configure output is:
>>>
>>> checking if we should zip debug-info files...
>>>
>>> with no result as $enable_zip_debug_info is unset.
>>>
>>> This simple patch makes the option use the more standard
>>> AC_ARG_ENABLE form used elsewhere and will
>>> print the default ('yes') when the option is unspecified:
>>>
>>> checking if we should zip debug-info files... yes
>>>
>>> What actually took longer than the fix was updating the generated
>>> files.  We seem to have already settled
>>> on autoconf 2.67 for generating the configure script, so my initial
>>> attempt threw up a huge number of changes
>>> as the system install is 2.69.  I was able to get it down to
>>> something closer to what is expected by installing
>>> a local copy of 2.67 but it's still not perfect.  I don't know why.
>>>   I've never been a fan of including generated
>>> files for this reason.
>>>
>>> So this script also updates autogen.sh to see if there is an
>>> autoconf-2.67 available and use that in preference
>>> to autoconf if it is.  I also added a little debug output so we can
>>> see which autoconf is being used in autogen.sh.
>>>
>>> If this is ok, can you please allocate it a bug ID and let me know
>>> which tree to commit it to.
>>>
>>> Thanks,