On 13/03/2013 11:58 PM, Andrew Hughes wrote:
----- Original Message -----
Andrew,
FWIW we are not tied to autoconf 2.67. There have already been a
number
of pushes using 2.68 and now 2.69 is also showing up.
Yes, Omair was kind enough to point me to this changeset which indeed
uses 2.68:
http://hg.openjdk.java.net/jdk8/build/rev/145dbc56f931
It would be nice to settle on one version though, if the generated file is
going to be checked into the repository, otherwise everyone who has a different
version installed is going to make lots of spurious changes to that file which
obscure the real change.
FWIW I rarely pay any attention to the actual generated-configure.sh in
doing a review. I only look at the changes to the m4 files etc. There's
just too much noise. Any cross-platform build issues will be readily
detected, and it's not likely the issues would be recognizable from the
source code.
Fixing on one version is a problem when so many different machines can
be involved in doing the builds. I have 2.68, no matter how I tried I
couldn't get it to use the 2.67 that I had installed privately/locally -
so I gave up.
David
-----
FWIW, gcc also includes the configure file in its Subversion repository and a
specific
version is used to update it.
David
On 13/03/2013 10:18 PM, 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,
