On 7/5/2010 2:48 AM, Gary V. Vaughan wrote: > > Just to clarify, that isn't what I meant -- rather, "well, I disagree, and > as you can see, despite its faults, patch X alone already makes things > less bad than they were previously. Is it okay if I push X in its current > state, and then tackle Y later? I've no inclination to work on Z, but > I'll put a reference to this thread in libtool/TODO so it isn't entirely > forgotten." > > And I believe that we'll often say "sure", or "good point, go ahead".
I see, thanks. ... >> Since that's really slow...I figured only windows $hosts should pay that >> penalty (even if the penalty only occurs during LT_OUTPUT). > > ...which is why I suggested having the complex, hard-to-quote-properly > implementations written directly into ltmain.m4sh, and then using > _LT_PROG_XSI_REPLACE to overwrite them with stubs at configure time. D'oh. Yeah, that make sense. >> Ack -- that's why my version was named _LT_PROG_FUNCTION_REPLACE (the >> other was that I needed a different internal implementation of that >> macro, as described above). > > Then I can use _LT_PROG_FUNCTION_REPLACE as the new name for existing > _LT_PROG_XSI_REPLACE? Sure, unless you think up something better. >> But...according to Ralf's message, this discussion is OBE. I'll revert >> back to a revised version of the 'take 7' patch. > > OBE? Order of the British Empire? Out of Body Experience? Overcome by events == no longer pertinent. -- Chuck
