public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@redhat.com>
To: Nathanael Nerode <neroden@twcny.rr.com>
Cc: klee@apple.com, gdb-patches@sources.redhat.com,
	binutils@sources.redhat.com, newlib@sources.redhat.com,
	gcc@gcc.gnu.org
Subject: Re: [RFC] Update to current automake/autoconf/libtool versions.
Date: Thu, 05 Dec 2002 11:31:00 -0000	[thread overview]
Message-ID: <3DEFA97F.8070407@redhat.com> (raw)
In-Reply-To: <20021205190728.GA11507@doctormoo>


> I really would like to see the tree using autoconf 2.5x as soon as 
> possible; if this can be done before I autoconfiscate the top level 
> (which is not autoconfiscated yet) it will save me an awful lot of 
> trouble, since I can then use autoconf 2.5x for that autoconfiscation. 
> :-/
> 
> Your patch as is updates
> bfd binutils gas gdb gprof ld mmalloc opcodes rda sim utils
> 
> Can you please work up a patch for gcc 3.4 to update
> boehm-gc fastjar gcc libf2c libffi libiberty libjava libobjc 
> libstdc++-v3 zlib

Just a step back here.  Some of the directories listed below belong to 
the FSF, but some don't.  I don't think anyone can be asking Klee to 
update non FSF code.  That's why I asked Klee to drop RDA from the 
original list.

> And a patch for Insight
> itcl libgui
> 
> And one for Dejagnu
> dejagnu expect

> And for Newlib & Cygwin
> libgloss newlib winsup
> 
> And one for
> sid
> 
> and one for
> intl
> 
> --
> However, I think that it's OK to update one directory at a time, 
> provided we specify clearly what's going on, and get it all done before 
> the next release of anything.

I don't think we can guarentee that, but I think we can live with the 
consequences :-/

> Accordingly, I suggest getting clean patches for small sets of 
> directories, making sure they work, getting them reviewed, and then 
> putting them in; and then starting on the next set.  Keep sending update
> notices to the various lists regarding which directories use the 'new' 
> tools and which use the 'old'.  If you can make scripts which work 
> correctly under *both* autoconf 2.5x *and* autoconf 2.13, by all means 
> do so *first*, and mark those scripts as "compatibile with both", of 
> course; but I expect that will only happen for the simplest directories.
> 
> If this is acceptable to other people in the various groups of course.
> 
> I expect this will generate a certain amount of breakage, but then so 
> did my changes.  In both cases, it needs to be done, we just have to 
> make sure all the breakage gets fixed.

Andrew

> --Nathanael
> 
> P.S.
> It was mentioned that autoconf2.5 scripts will have trouble with 
> building because of the top level passing down --target unconditionally.
> 
> Unfortunately I think some other aspects of the configure scripts 
> require --target to be passed down unconditionally. :-/  Otherwise I'd 
> just change it.
> 
> 
> 


  reply	other threads:[~2002-12-05 19:31 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-05 11:08 Nathanael Nerode
2002-12-05 11:31 ` Andrew Cagney [this message]
2002-12-05 13:31 ` Zack Weinberg
2002-12-05 14:29   ` Alan Modra
2002-12-05 15:14     ` Ian Lance Taylor
2002-12-05 15:32       ` Alan Modra
2002-12-05 15:45         ` Ian Lance Taylor
2002-12-05 16:26           ` Andrew Cagney
2002-12-05 15:47         ` Mike Stump
2002-12-05 16:30           ` Alan Modra
2002-12-05 16:36             ` Zack Weinberg
2002-12-08  2:48         ` Klee Dienes
2002-12-05 14:07 ` Christopher Faylor
2002-12-06  7:25 ` Maciej W. Rozycki
2002-12-08  3:23 ` Klee Dienes
2003-01-12 17:51 ` [RFC] Update to current automake/autoconf/libtool versions (take 2) Klee Dienes
2003-01-12 20:34   ` Nathanael Nerode
2003-01-12 20:54   ` Zack Weinberg
2003-01-13 10:24     ` Klee Dienes
2003-01-13 14:17       ` Zack Weinberg
2002-12-05 14:36 [RFC] Update to current automake/autoconf/libtool versions Nathanael Nerode
2002-12-05 15:19 ` Zack Weinberg
2002-12-06  9:33   ` Tom Tromey
2002-12-07 12:55   ` Alexandre Oliva
2002-12-07 13:19     ` Zack Weinberg
2002-12-09 18:57       ` Alexandre Oliva
2002-12-09 21:52         ` Geoff Keating
2002-12-08 13:48     ` Tom Tromey
2002-12-05 14:40 Joern Rennecke
2002-12-10 19:33 Henry Nelson
     [not found] <20021206005522.GA11907@doctormoo>
     [not found] ` <87of7sa16x.fsf@egil.codesourcery.com>
2002-12-12 13:29   ` Nathanael Nerode
2002-12-13  5:31     ` Alexandre Oliva
2003-01-01 10:39 Nathanael Nerode
     [not found] <9A4230D6-1D26-11D7-BFCA-00039396EEB8@apple.com>
2003-01-12 20:20 ` Alexandre Oliva

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=3DEFA97F.8070407@redhat.com \
    --to=ac131313@redhat.com \
    --cc=binutils@sources.redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=klee@apple.com \
    --cc=neroden@twcny.rr.com \
    --cc=newlib@sources.redhat.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).