On libtool patches for 3.0.1

[Alexandre Oliva <aoliva at redhat dot com>]

I couple of patches have been posted for libtool files since the 3.0
release, and I'd like to somehow accept them for 3.0.1, but we have a
bit of a problem.  By policy, we never check in local changes to
libtool files.  The rationale for this policy is that, when I approved
such patches in the past, but failed to check them in the libtool CVS
tree, they were eventually backed out, or never made it to the libtool
CVS tree.  I.e., this policy is to make up on my personal inability to
track patches that make it to GCC but don't make it to libtool, and it
helps make sure the version number of libtool files in GCC is in line
with the libtool version numbering.

It turned out that the libtool multi-language branch, from which we
used to import the libtool files, was merged into libtool mainline and
declared dead.  However, the merge included a huge change, that folded
all of ltconfig and the ltcf-*.sh files into libtool.m4.

It's a major step in the right direction: the folding of ltconfig into
libtool.m4, so that its code becomes part of the configure script, is
probably going to save us from the cache-coherence and
brain-dead-shells problems we have with the current version.

The problem is that the change was so large that I feel it is probably
way too risky to do a new blind import of libtool into the GCC 3.0
branch for 3.0.1, even though I intend to start testing that
possibility, possibly with the next snapshot GCC.

It's very unfortunate that this libtool major change came up at such
an inconvenient time, but it was a long-overdue change, and I'm very
happy Gary V. Vaughan has finally had time to undertake it.


But back to the point: what are we going to do with patches for
libtool files that we'd like to have in release 3.0.1?  I'm trying to
get approval from the other libtool developers to re-open the former
multi-language branch, so that it could still be used as the basis for
imports into the GCC 3.0 branch.  However, even then, the libtool
folks (myself included) would still require patches to fix problems or
introduce features in mainline, not (only) in the MLB.  And we really
want to have the patches for mainline too, so that, whenever we adopt
this newer version (hopefully in the near future, in GCC mainline), we
don't have regressions (even if the import also happens to fix other
problems or introduce new features :-D :-D

Libtool developers would hopefully be willing to cooperate with
contributors helping port patches from MLB to mainline, or perhaps
even doing the port on-the-fly, as the patch is installed in MLB.  But
if you have a pending patch for libtool files in the GCC tree, please
make sure it's been posted to libtool-patches@gnu.org, and, if
possible, port it over to the current libtool mainline too.  This will
probably help speed up the process of evaluation (and hopefully
approval) of the patch for the libtool CVS tree, so that we can have
the patch in the GCC CVS tree earlier.


The alternative is to start checking in changes in the GCC 3.0 branch
that are not backed by corresponding changes in libtool MLB (now
deceased :-), which I dislike because then we'd be changing
machine-generated files, which might make it harder to port the
patches over to libtool mainline.  In this case, we'd mark the libtool
version numbers in the 3.0 branch as GCC-local, and document the
policy change for the branch.

Comments?

I'm very sorry about being so unresponsive in libtool issues in the
recent past.  I couldn't do better :-(

I hope we can reach a resolution about what to do regarding libtool
patches in the near future, but I'm afraid the patches will have to
remain on hold for a little bit longer.  Please accept my apologies
for that, and don't blame other libtool developers for my own
limitations.

-- 
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