This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Reapply patch lost during recent "blind import" oflibtool
On Apr 12, 2001, Loren James Rittle <rittle@latour.rsch.comm.mot.com> wrote:
> Yikes! I didn't even know there was an ltconfig.in. In the gcc
> source tree, we only have ltconfig. ltconfig makes no mention that
> it is generated from another file thus I didn't even know I was
> making life hard for libtool maintainers when I sent patches against
> ltconfig.
It's not as bad as it seems. ltconfig differs from ltconfig.in
basically only in the fact that it gains a version number and a
timestamp, and line numbers in #line directives of here-documents are
fixed up. Similarly for ltmain.sh and ltmain.in.
This is likely to change in the future. It's very likely that
ltconfig.in, and all of ltcf-*.sh, will be folded into libtool.m4, and
that ltmain.in will be rewritten in some macro-processing language
(AutoGen or autoconf 2.50's m4sh).
> However, we should still consider tracking libtool and other
> external sources in the gcc source tree via vendor branches instead
> of plain checkins.
I don't have a strong opinion about this. At first, I like the idea
of enforcing import-only updates. On the other, it would seem to
prevent temporary work-arounds for problems, whenever the maintainers
of libtool become unresponsive. Well, one can always import files
that consist solely of a single patch, instead of a full import, so we
don't really lose any abilities, whereas we gain warnings for those
who don't know about the rules.
Yeah, the more I think about this, the more I like it.
--
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