From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Daniel Jacobowitz <drow@false.org>
Cc: DJ Delorie <dj@redhat.com>,
gcc-patches@gcc.gnu.org, binutils@sourceware.org,
gdb-patches@sourceware.org, newlib@sourceware.org
Subject: Re: Updating top-level autoconf to 2.59
Date: Fri, 09 Feb 2007 17:39:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64N.0702091717250.1045@blysk.ds.pg.gda.pl> (raw)
In-Reply-To: <20070209161658.GA13966@nevyn.them.org>
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
next prev parent reply other threads:[~2007-02-09 17:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070111225346.GA1335@nevyn.them.org>
[not found] ` <20070207193352.GA13757@nevyn.them.org>
[not found] ` <xnr6t1hdvt.fsf@greed.delorie.com>
2007-02-08 22:20 ` Daniel Jacobowitz
2007-02-08 22:30 ` DJ Delorie
2007-02-08 22:38 ` Daniel Jacobowitz
2007-02-08 22:44 ` DJ Delorie
2007-02-08 22:54 ` DJ Delorie
2007-02-09 15:16 ` Daniel Jacobowitz
2007-02-09 15:37 ` Maciej W. Rozycki
2007-02-09 15:39 ` Daniel Jacobowitz
2007-02-09 16:14 ` Maciej W. Rozycki
2007-02-09 16:17 ` Daniel Jacobowitz
2007-02-09 16:33 ` Andreas Schwab
2007-02-09 17:39 ` Maciej W. Rozycki [this message]
2007-02-09 17:42 ` Daniel Jacobowitz
2007-02-09 17:53 ` Maciej W. Rozycki
2007-02-09 17:48 ` Steve Ellcey
2007-02-09 20:45 ` Tom Tromey
2007-02-13 9:25 ` Maciej W. Rozycki
2007-02-13 10:30 ` Andreas Schwab
2007-02-09 16:29 ` Joseph S. Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64N.0702091717250.1045@blysk.ds.pg.gda.pl \
--to=macro@linux-mips.org \
--cc=binutils@sourceware.org \
--cc=dj@redhat.com \
--cc=drow@false.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=newlib@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox