This is the mail archive of the
mailing list for the GCC project.
Re: Doc for autoconf and automake versions
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: "Joseph S. Myers" <jsm at polyomino dot org dot uk>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, java at gcc dot gnu dot org, fche at redhat dot com, bonzini at gnu dot org
- Date: Mon, 14 Jun 2004 12:21:40 -0500
- Subject: Re: Doc for autoconf and automake versions
- Organization: Red Hat / Chicago
- References: <Pine.LNX.email@example.com>
>I also hope that libcpp and libstdc++-v3 can
>have their files regenerated with automake 1.8.5, as used for
>libgfortran, so that only one 1.8.x version is needed.
Done for libstdc++.
2004-06-14 Benjamin Kosnik <firstname.lastname@example.org>
* Makefile.in: Regenerate with automake 1.8.5.
* aclocal.m4: Same.
* include/Makefile.in: Same.
* libmath/Makefile.in: Same.
* libsupc++/Makefile.in: Same.
* po/Makefile.in: Same.
* src/Makefile.in: Same.
* testsuite/Makefile.in: Same.
>Where was the introduction of use of a third automake release series
>(1.8.x) without getting rid of at least one of the previous versions
>at the same time discussed? Even during transitions, I think we
>should have no more than two versions of either autoconf or automake
>in use in the tree at once, and when a new bug-fix automake comes out
>(successive 1.8.x versions) the whole tree and documentation should be
>updated at once rather than having the versions diverge.
This would be preferred, but I think the continued migration upwards on
the 1.8.x automake versions is reflecting a desire to not get stuck on
any version, and instead track the current release. At least, that's how
I see it.
If you are volunteering to keep everything in sync (perhaps by messages
such as this), I think it sounds like a great idea.