libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

alpha release schedule [Was Re: ok, new libtool for cygwin updates]


From: Gary V . Vaughan
Subject: alpha release schedule [Was Re: ok, new libtool for cygwin updates]
Date: Fri, 30 Mar 2001 18:34:40 +0100

On Friday 30 March 2001  4:07 am, Alexandre Oliva wrote:
> 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.

Oh yes, I know the one you mean... I didn't associate it from your original 
description.  Doh!

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

Fair enough.

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

It would be nice to get some of that old momentum going again =)O|

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

I wasn't thinking of us so much (though I do seem to spend a lot of my 
libtool hacking time porting patches back and forth between the branches), 
rather that the number of eyes looking at the development code is halved by 
having twice as many branches.

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

Having a support branch for occasional bug fixes is fine by me.  I have come 
to dislike having multiple simultaneous development branches. :-/

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

I'm not sure how to arrange for them to be called at the right time, but that 
should become clear when I get chance to look at the code.

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

Yuck!  But if you don't mind all that merging, I'll take care of the ltc*f* 
elimination.  However, I don't plan to worry about that until after 1.4, 
which is at least a week or two away depending on whether we find any bugs in 
the next alpha release.

Anyway, I'll fix the duplicate libs bug and post back here for a final check 
before rolling up 1.3d.

Cheers,
        Gary.
-- 
  ___              _   ___   __              _         mailto: address@hidden
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       address@hidden
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc



reply via email to

[Prev in Thread] Current Thread [Next in Thread]