Re: libtool and cl

[Braden McDaniel]

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: <address@hidden>
<http://endoframe.com>                    Jabber: <address@hidden>