[avail for test] libtool-devel-20030121-1

[Charles Wilson]

Ralf Habacker wrote:
> Chuck, about two month ago we had a private discussion about the file_magic
> stuff, where i have investigated about 7 hours to figure out a faster approach
> for identifing import library file types, because the implementation you have
> mentioned would increase the kde compiling time more than about 70 % (that means
> 6,8 hours instead 4 hours for a full recompile, which is inacceptable  for me).
> Probably you remember this stuff, if not I can send you the thread. So it seems
> to me, that you only like to get my confirmation about your solution and nothing
> else.

Not true.  As I remember, I was focused on fixing *brokenness* in CVS 
libtool.  I believe the thread to which you refer was concerned with the 
"cygwin has only static gcc/g++ runtime libs" bug, not the "libtool on 
cygwin rebuilds exe's unnecessarily" bug.  There were lots of bugs to 
choose from.

So, as I said, I wanted to confirm (back then) that my fix corrected the 
static runtime problem. You were complaining about speed -- and 
suggested improvements, for which I am grateful but judged the time was 
not right.  I wanted to squash all of the known bugs first, before 
introducing speedups -- especially speedups like yours that were 
deliberate "speed over pedantic correctness" optimizations.

Since iteration #6 of my (et. al.) fix for the rebuild-exe bug has 
finally been absorbed into CVS, I now consider all *major* outstanding 
bugs in cygwin libtool-devel squashed.  That means *now* is the time for 
speed improvements -- now we can introduce new exciting bugs.  And yes, 
Ralf, I did expect that you would raise that issue now.  I'm glad you 
did -- I want some sort of speedup fix to go into CVS -- but you did the 
coding.  Therefore you'll have to submit it and assign copyright, etc 
etc.  I can't.

Of course, I'll argue against your most aggressive version (I believe 
you had an aggressive one, and a moderate one) because IMO the 
aggressive patch was far too cavalier about false positives/negatives.

But now's the time (two months ago was not).  Post 'em to libtool-patches.

[snip]

> the auto-import-from-dll-stuff (probably you don't know this
> cause), so this may not be wath you have expected, but think about if this isn't
> also a good contribution.

Sure, I liked this.  I advocated heavily for its eventual inclusion in 
binutils.  It's possible that post-1.5, libtool might use the 
symlink/copy-of-dll as an import lib, in most cases.  But 1.5 is 
**imminent**.  There's not enough time for a major change like that to 
stabilize; besides, it's a platform issue as well as a libtool issue. 
That sort of thing should be decided not just by you, or me, or the 
libtool folks, but should be thoroughly hashed out on the cygwin and 
mingw lists.

> next month. not earlier, sorry. This is reason for the
> contribution right now.

That's fine.  It won't make it into 1.5, but 1.5.1 and friends will be 
coming along afterwards.  And hopefully without the two year delay like 
we saw between actively developed 1.4.x and 1.5...

> (kde3 for example libtool 1.4e, automake 1.5/1.6) release and so following the

I understand sticking with "real" libtool (but a CVS version of the 
1.4.x branch?  That's odd...) But I don't understand staying with the 
increasingly obsolete am-1.5 and am-1.6 releases.  Those crazy kde 
people...even gcc/binutils are finally coming into the 21st century...

> If you would have asked, I would have said:
> Please wait until I'm going to the kde3 build fix and than I can help. Sorry.

It's not that you didn't chime in with your speedup patches.  Its that 
you apparently didn't bother to read the emails in the discussion, so 
that when you DID chime in, it was with (slightly) offtopic and (mostly) 
unhelpful at this late date.

> which is named "overload". :-)

You got that right.  I'm in major overload mode right now.  Big time.

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/