mini-freeze of autotools-governed files in GCC and src

mini-freeze of autotools-governed files in GCC and src

[Ralf Wildenhues]

Please refrain from committing changes to autotools-governed files
(their input files such as configure.ac, Makefile.am, *.m4 macro files,
and their products configure, aclocal.m4, ...) for the next few hours,
to the GCC, the binutils, and the gdb trees.

I'll announce the end of this mini-freeze after moving the trees to use
2.64/1.11.

Thank you,
Ralf

Re: mini-freeze of autotools-governed files in GCC and src

[NightStrike]

svn lock?

On Sat, Aug 22, 2009 at 7:07 AM, Ralf Wildenhues<Ralf.Wildenhues@gmx.de> wrote:
> Please refrain from committing changes to autotools-governed files
> (their input files such as configure.ac, Makefile.am, *.m4 macro files,
> and their products configure, aclocal.m4, ...) for the next few hours,
> to the GCC, the binutils, and the gdb trees.
>
> I'll announce the end of this mini-freeze after moving the trees to use
> 2.64/1.11.
>
> Thank you,
> Ralf
>

Re: mini-freeze of autotools-governed files in GCC and src

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Sat, Aug 22, 2009 at 01:07:23PM CEST:
> Please refrain from committing changes to autotools-governed files

Freeze is over.  Thanks for your patience.

The trees have been updated to Autoconf 2.64 and Automake 1.11.  Please
take a minute to ensure that you use these tools now when changing build
system generated files; and that you have them early in your $PATH if
you build with --enable-maintainer-mode.

You might have to start with a clean build tree if you use
--enable-maintainer-mode, otherwise, you might still at least have to
remove all config.cache files from an existing build tree that was built
before this freeze.

For binutils, you likely have to start off with a clean build tree
(i.e., you need to reconfigure).  If your compiler doesn't allow for
side-effect dependency-tracking, try --enable-dependency-tracking.

Please feel free to Cc: me for all bug reports that are or look like
they could be related to the new autotools versions.

I'll work on patches for the remaining parts of src to get them updated
and finish some of the leftover cleanups.

Thanks,
Ralf

Re: mini-freeze of autotools-governed files in GCC and src

[Kaveh R. GHAZI]

On Sat, 22 Aug 2009, Ralf Wildenhues wrote:

> Freeze is over.  Thanks for your patience.

Thanks for your work on this!

> The trees have been updated to Autoconf 2.64 and Automake 1.11.  Please
> take a minute to ensure that you use these tools now when changing build
> system generated files;


Why request developers ensure this and not bump the AC_PREREQ to make
sure?

Re: mini-freeze of autotools-governed files in GCC and src

[Ralf Wildenhues]

* Kaveh R. GHAZI wrote on Sun, Aug 23, 2009 at 03:31:00PM CEST:
> On Sat, 22 Aug 2009, Ralf Wildenhues wrote:
> 
> > The trees have been updated to Autoconf 2.64 and Automake 1.11.  Please
> > take a minute to ensure that you use these tools now when changing build
> > system generated files;
> 
> Why request developers ensure this and not bump the AC_PREREQ to make
> sure?

Toplevel config/override.m4 should already cause failure if you use
anything other than Autoconf 2.64 (but it doesn't ensure Automake 1.11).

However, if override.m4 isn't included in some directory (because that
hasn't been done yet, or because somebody ran aclocal with missing -I
arguments), then the test isn't used.  So it's debatable whether
AC_PREREQ would help for that case.  Since we pretty much require
override.m4 to fix a bug in 2.64, however, that doesn't really gain us
all that much.  Better to just ensure it is used everywhere.

A few followup patches to binutils ensure Automake 1.11 there.  I can
write one to ensure it in GCC as well (or think about a way to do it in
override.m4) if that is desired.

Cheers,
Ralf

Re: mini-freeze of autotools-governed files in GCC and src

[Kaveh R. Ghazi]

From: "Ralf Wildenhues" <Ralf.Wildenhues@gmx.de>

>> Why request developers ensure this and not bump the AC_PREREQ to make
>> sure?
>
> Toplevel config/override.m4 should already cause failure if you use
> anything other than Autoconf 2.64 (but it doesn't ensure Automake 1.11).

In addition to enforcing the version number, the AC_PREREQ in all the 
configure.ac files documents to the reader of the file what version to use. 
It's now out of date and a source of possible confusion.  I would suggest 
either (preferably) updating them all to 2.64 or removing them.