libtool
[Top][All Lists]
Advanced

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

Re: libtool and cl


From: Charles Wilson
Subject: Re: libtool and cl
Date: Sat, 29 Mar 2003 18:05:22 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130

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.

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.

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.

--Chuck






reply via email to

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