Re: ok, new libtool for cygwin updates

[Alexandre Oliva]

On Mar 29, 2001, "Gary V. Vaughan" <address@hidden> wrote:

> On Friday 30 March 2001  2:23 am, Alexandre Oliva wrote:

>> Not really.  We really must fix the bug that causes us to remove
>> duplicate libraries before releasing 1.4.

> Huh?  Seems like I'm missing something here.  What is this bug exactly?

There is this chunk of code that removes duplicate `-l' flags that
appear in a link command.  The order of `-l' flags is relevant; we
tell whether it's safe to remove -l flags from the beginning or from
the end without looking into all other libraries.  So we shouldn't do
it.

> If it is not a showstopper

It is.  It's so wrong that I don't even understand how it may have
survived for so long with so few complaints.

> After that I'm inclined to experiment with more 
> regular alpha releases -- say one a month except where we discover 
> showstoppers in CVS which would need to be fixed before making an alpha 
> release.

This would be excellent.

> Infact, I'm keen to remove the multiple branches philosophy which has helped 
> to slow development so much in the last year or two

Personally, I can't blame the multiple branches for not having had
time to devote to libtool.  But they certainly don't help.

In any case, we're always going to have at least two branches, one
with the previous point release plus bug-fixes, and one for
development.  Not that different from what we have now, given that you
consider the 1.3 branch dead :-)

> I'd be happy to redo the ltconfig elimination in MLB after 1.4 and
> before the merge.

I'm of the opinion that we should eliminate not only ltconfig, but
also all of the ltcf-*.sh files.  They should all be folded into m4
macros.  But I suppose this is no big deal.

> Maybe we could agree to break MLB for a while so that I can 
> eliminate ltconfig, but leave someone more intimate with tags to get them 
> working again afterwards?

tags are an essential feature of MLB.  Without having tags, there's no
multi-language support, since a tag is what defines a language.  So,
if it's to be broken, I'd rather have it broken in a branch, so that
we have a working MLB while the conversion is ongoing.

So, how about branching 1.4 off now (or right after duplicate-removal
is removed), moving the MLB to mainline, tagging MLB with
MLB-before-m4-conversion, converting it to *.m4 in the branch, then,
when the conversion is complete, merge it again, with changes based on
the tag?

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