This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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


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.


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]