Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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