Re: Reapply patch lost during recent "blind import" of libtool

[Alexandre Oliva <aoliva at redhat dot com>]

On Apr 11, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
Alexandre> I'd much rather have local annotations of GCC-local
Alexandre> changes, if they're at all needed.  I did look for such

> Why put markers in the source?  

At the very least, so that someone who gets these files knows it's not
a pristine release of libtool, but something modified for GCC.  In a
perfect world, we'd never need to modify files in the GCC tree: we'd
just get patches installed in the libtool CVS tree and merged here.
I'm trying to keep this part of the world as perfect as possible.

In any case, whenever there are local changes to libtool files, at the
very least the version number should be modified.  Against my advice,
it never was.

> We have CVS to keep track of these kinds of things -- that's what tags
> and vendor branches are for.

I know very well how to deal with CVS for these things.  I also know
very well how much time I lose every time I import a new version of
libtool into other CVS repos, just to fix the merge conflicts, that
shouldn't even be there in the first place, but that somehow show up.
I don't want to waste that much time with libtool in GCC.  It's not
necessary.  We just don't need local changes.  We need to make sure
fixes get propagated upstream.  I'm willing to no longer accept
patches for the local copies of these files.  That's exactly what we
do with config.guess and config.sub.  Why should the libtool files be
any different?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me