Maciej W. Rozycki - Re: Updating top-level autoconf to 2.59 (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

On Fri, 9 Feb 2007, Daniel Jacobowitz wrote:

On Fri, Feb 09, 2007 at 04:13:43PM +0000, Maciej W. Rozycki wrote:

I see, though frankly I wouldn't consider switching from 2.59 to 2.61 too much of a project. And certainly much less than doing the 2.13 to 2.59 conversion at the top level. Of course in 2.61 there may be different bugs than in 2.59, but I gather the new version is not meant to imply any kind of revolution. Even if there were some subtle problems somewhere, they should get sorted out as things go by stage 3.

Or is it because of the new structure of install directories?

There's simply too many directories. We'd want to upgrade all of src and gcc at once.

Sure -- I use a script like this for regenerating all the scripts:

for name in find . -name 'configure.[ai][cn]' -exec dirname "{}" \;; do (cd $name && autoconf) STATUS=$? if [ $STATUS -ne 0 ]; then exit $STATUS fi done

I have similar scripts for running libtoolize', aclocal', autoheader' and automake' if interested. They should make the tree consistent, though configuring and running make' may be necessary afterwards and before committing the changes for some timestamps to be updated (most notably for results of autoheader').

BTW, do we still want to carry local copies of severely obsolete libtool scripts? I have had success with libtool 1.5.22 and GCC 4.1.1 after a moderate amount of work (mostly shuffling bits around; libjava/ was the most involving part) -- if there is interest in upgrading (which might help some people with less common configurations) I could port them to the trunk sooner rather than later.

And yes, there are some troublesome changes - like, if you don't adjust your makefiles, you get warnings about ignoring datarootdir.

Indeed, though they are not fatal. Perhaps Makefile.in files in the affected directories (Makefile.am are OK as sufficiently new automake will deal with that) could get updated beforehand? It should not hurt at all.

Maciej


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]