Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Klee Dienes <klee@apple.com>
To: Alan Modra <amodra@bigpond.net.au>
Cc: zack@codesourcery.com, neroden@twcny.rr.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: Sun, 08 Dec 2002 02:49:00 -0000	[thread overview]
Message-ID: <A4449CEC-0A9A-11D7-9779-00039396EEB8@apple.com> (raw)
In-Reply-To: <20021205231909.GY27956@bubble.sa.bigpond.net.au>

On Thursday, December 5, 2002, at 06:19 PM, Alan Modra wrote:

> On Thu, Dec 05, 2002 at 02:55:38PM -0800, Ian Lance Taylor wrote:
>> Perhaps --enable-maintainer-mode could be extended to specify a PATH
>> to use to find the tools.
>
> It would need to be on a per-directory basis.  Something like
>
> --enable-maintainer-mode=\
> "gdb:/usr/local/000227/bin,libstdc++-v3:/usr/local/oldauto/bin,*:yes"

What if the rules generated by --enable-maintainer-mode were to pass a 
version number to each of the tools when using them to re-generate 
files?  The version number passed would be the same version number used 
to generate the existing version of the generated files.  Then the 
autotools could either dispatch to the correct version of the tool 
based on the version number, or
perhaps generate an error if the version numbers did not match.  In 
order to upgrade the generated files in a directory to a newer version, 
the user would have to explicitly run autoreconf or run he appropriate 
autotools directly.

This would make it a lot harder for a maintainer to accidentally use 
the wrong version of an autotool when regenerating files in a 
directory.  It would also make it possible to write a top-level script 
that would explicitly re-generate all of the files in a tree with 
explicitly specified versions (or at least verify that the versions 
being used were correct).

Regardless of how we choose to do it, though, I think it's important 
that maintainers be able to update individual subdirectories to newer 
versions of the autotools independently of each other (even if the way 
we choose to do that is to say "don't run global 
--enable-maintainer-mode, and be aware of the versions of the autotools 
you are using").  If we don't, the bar for updating versions of 
autotools is just too high.  Trying to coordinate a simultaneous 
upgrade of even a simple change across the combined src+gcc repository 
is a huge amount of work --- if that's the only way to do upgrades, it 
seems much more likely that the upgrades will tend to not get done.  
The thought of even *touching* sid is daunting to me, much less the 
thought of trying to claim that I've changed all of its Makefiles and 
understand the changes.


  parent reply	other threads:[~2002-12-08 10:48 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-05 11:08 Nathanael Nerode
2002-12-05 11:31 ` Andrew Cagney
2002-12-05 13:31 ` Zack Weinberg
2002-12-05 14:36   ` Alan Modra
2002-12-05 14:56     ` Ian Lance Taylor
2002-12-05 15:22       ` Alan Modra
2002-12-05 15:43         ` Ian Lance Taylor
2002-12-05 15:51           ` Andrew Cagney
2002-12-05 15:47         ` Mike Stump
2002-12-05 16:30           ` Alan Modra
2002-12-05 16:45             ` Zack Weinberg
2002-12-08  2:49         ` Klee Dienes [this message]
2002-12-05 14:29 ` Christopher Faylor
2002-12-06  6:45 ` Maciej W. Rozycki
2002-12-08 10:53 ` Klee Dienes
2003-01-12 10:32 ` [RFC] Update to current automake/autoconf/libtool versions (take 2) Klee Dienes
2003-01-12 16:14   ` Nathanael Nerode
2003-01-12 17:14   ` Zack Weinberg
2003-01-13  3:32     ` Klee Dienes
2003-01-13  7:31       ` Zack Weinberg
     [not found] <9A4230D6-1D26-11D7-BFCA-00039396EEB8@apple.com>
2003-01-12 13:22 ` [RFC] Update to current automake/autoconf/libtool versions Alexandre Oliva
  -- strict thread matches above, loose matches on Subject: below --
2002-12-06  5:28 Nathanael Nerode
2002-12-05 14:42 Joern Rennecke
2002-12-05 14:40 Nathanael Nerode
2002-12-05 15:19 ` Zack Weinberg
2002-12-06 10:21   ` Tom Tromey
2002-12-07 13:06   ` Alexandre Oliva
2002-12-07 16:03     ` Zack Weinberg
2002-12-09 19:16       ` Alexandre Oliva
2002-12-09 21:52         ` Geoff Keating
2002-12-08 13:11     ` Tom Tromey
2002-12-05 10:15 Michael Elizabeth Chastain
2002-12-05 10:37 ` Klee Dienes
2002-11-13 10:32 [RFA/PATCH] Darwin fixes for ltconfig, ltcf-c.sh Klee Dienes
2002-12-04 22:04 ` [RFC] Update to current automake/autoconf/libtool versions Klee Dienes
2002-12-05  5:26   ` Hans-Peter Nilsson
2002-12-05 14:07     ` Alan Modra
2002-12-05  7:43   ` Andrew Cagney
2002-12-05  8:22     ` Klee Dienes
2002-12-05  9:01       ` Andrew Cagney
2002-12-05 12:55         ` Klee Dienes
2002-12-05 13:03           ` Daniel Jacobowitz
2002-12-05 13:13             ` Andrew Cagney
2002-12-05 13:16               ` Daniel Jacobowitz
2002-12-05 13:08           ` Andrew Cagney
2002-12-05 13:18             ` Klee Dienes
2002-12-05  8:28     ` DJ Delorie
2002-12-05  9:37       ` Klee Dienes
2002-12-05  9:42         ` DJ Delorie
2002-12-05 10:28           ` Klee Dienes
2002-12-05  9:31     ` H. J. Lu
2002-12-05  7:44   ` Maciej W. Rozycki
2002-12-05  9:01     ` Klee Dienes
2002-12-05  8:09   ` Daniel Jacobowitz
2002-12-05  8:29     ` DJ Delorie
2002-12-05  8:35       ` Daniel Jacobowitz
2002-12-05  8:37         ` DJ Delorie
2002-12-05  8:40         ` Maciej W. Rozycki
2002-12-05  8:44           ` Daniel Jacobowitz
2002-12-05  9:19             ` Elena Zannoni
2002-12-05  9:54             ` Klee Dienes
2002-12-05 10:10               ` Maciej W. Rozycki
2002-12-05 10:59               ` Doug Evans
2002-12-05 12:11                 ` Klee Dienes
2002-12-05 12:23                   ` Ian Lance Taylor
2002-12-05 14:29                     ` Klee Dienes
2002-12-06  5:34                 ` Maciej W. Rozycki
2002-12-06  7:25                   ` DJ Delorie
2002-12-06  8:06                     ` Maciej W. Rozycki
2002-12-06  8:47                       ` DJ Delorie
2002-12-05 10:59               ` Andrew Cagney
2002-12-06  5:52                 ` Maciej W. Rozycki
2002-12-05 13:59               ` Ben Elliston
2002-12-05 13:41                 ` Ben Elliston
2002-12-30 16:10   ` 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=A4449CEC-0A9A-11D7-9779-00039396EEB8@apple.com \
    --to=klee@apple.com \
    --cc=amodra@bigpond.net.au \
    --cc=binutils@sources.redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=neroden@twcny.rr.com \
    --cc=newlib@sources.redhat.com \
    --cc=zack@codesourcery.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