----- Original Message -----
> 
> 
> 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,
> 

Any progress on this?  Still needs a reviewer.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Reply via email to