On Sat, 2003-03-29 at 18:05, Charles Wilson wrote: > Braden McDaniel wrote: > > >>It used to be supported by libltdl, but when GCC implemented the > >>auto-import capability, Gary removed the support. I think it was a > >>bad idea to remove the support. There are plenty of reasons to use > >>the Microsoft compiler rather than GCC under Windows since GCC has > >>limited functionality under Windows. > > > > > > Any chance you recall the last release to include that support? > > 1.4.3 <g> > > Seriously, try CVS prior to May 31, 2001. That's when the first of the > auto-import stuff went into CVS AFAIK. > > But, for the love of pete, PLEASE do not re-add that cruft willy-nilly. > Keep it nicely segregated from mingw, cygwin, and pw support; I don't > want to see ANY of that creep back into the cygwin execution path. > > This will require significant refactoring of the code -- especially > since May 31, 2001 was ALSO prior to the multi-tag changes. Which means > that the old support knows nothing about multiple tags, in addition to > its "commingled" status wrt cygwin/mingw/gcc. > > Resurrecting that code will be a large chunk of work.
Thanks for the info. > Unfortunately, I don't have the time to rebuild on cygwin after every > commit to make sure stuff didn't get broken. PLEASE be careful not to > disturb the other windows-based compilers. This talk of mucking around > with libtool on "my" platform (e.g. windows; cl/mingw/cygwin/pw are all > somewhat related in the underlying OS) this close to 1.5's release gives > me the screaming heebie-jeebies. I've waited over two years for a > decent libtool -release- on cygwin that *really* supports building > shared libs transparently and in "the unix way"...it works now, and I'd > be terribly pissed to see it broken at T-3weeks. Unless 1.5 is a lot farther off than I hope it is, I have no expectation that such changes could go in prior to that release. > With respect to Bob, Gary's decision to remove it was correct at the > time. Unmaintained, untested code should NOT simply be carried along > because "it might be needed later". It would have made development on > actual used and tested platforms [e.g. cygwin/mingw] for the past 21 > months much harder, for very little benefit. The old code will always > be there -- in CVS archives -- if anybody wants to up-port it. But no > one did, and no one was available, and apparently no one needed it until > now. That's 21 months of pain, avoided. I'm cool with that. > > Also wrt Bob, concerning mingw vs cl: IMO, if you're using cl and > relying on its non-standard extensions to C and C++, then you are > obviously not trying to write portable code. In that case, you should > simply use the MSVC support for building DLLs and static libs, and NOT > use libtool or autoconf or automake at all. Since you're not worried > about portability, use the tools MS provides to make your life easier; > why go thru the pain of creating a *build* system that is portable, when > your *code* is not? The autotools are about portability. Using cl does not imply "relying on its non-standard extensions". As it happens, a *lot* of portable code gets compiled with cl. It would be very useful to be able to use the autotools in that situation. -- Braden McDaniel e-mail: <[EMAIL PROTECTED]> <http://endoframe.com> Jabber: <[EMAIL PROTECTED]> _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
