Re: MSYS+MSVC for libtool branch-2-0

[Ralf Wildenhues]

Hi Peter,

* Peter Ekberg wrote on Tue, May 24, 2005 at 11:51:08PM CEST:
> 
> I started an attempt to support the MSVC compiler natively

Cool!  I started looking at this a couple of weeks ago, but have had no
time to pick up on it again.  I have made a couple of notes, though,
which I can post sometime.

> (w/o the cccl script, which I haven't tried to be honest)
> and using MSYS to drive the scripting.

OK.  If we tune up MSVC support in Libtool, we should do it right,
meaning that we should (at least allow for) different MSVC versions and
probably either one of CYGWIN or MSYS scripting.  And we should probably
also allow to use cccl, or even require it if that makes life a lot
easier.  (We should also allow for support for other compilers on win32,
but I for one was not smart enough for the Borland online sheet.)

Which MSVC version do you use?  By looking at whatever rough
support there is (was once installed) in Libtool, that pertains to an
old version.  Unfortunately, I don't have access to such an old version.
If we can get hold of it, though, I think we should not kill its support
by changing the libtool.m4 settings (unless they are broken, that is).

> With this (rough) patch I am able to build and use shared libraries
> (libs and modules) and convenience libraries. I haven't tested static
> libs (I haven't gone through the pain of bootstraping on Cygwin, which
> would require building some current autotools from scratch.)

I have started working on old libs.  AFAICS, the `LIB' program has
been replaced with `LINK -lib' in one of the newer MSVC versions.

I also believe that (at least the newer) archiver encodes paths into the
objects, so we might have to move/copy objects around before creating
it.  OTOH, we could also think of supporting MSYS `ar' while using 

> I realize that this is not likely an acceptable patch.

No.  :)
But it's a start.  I'll try it out when I have time (could be a while).
Generally, you should avoid putting system-dependent stuff into ltmain.
For example, `LIB' and tests for $host should be parameterized; yes,
there are quite a few cases where that is not done currently, but we
should try to minimize any further regressing to that end.

> Perhaps libname_spec should be just $name on MSVC? Instead
> of doing that, I added a second very similar loop in
> ltmain.sh, but that might be a cludge?

Need to look at this closer.

> This patch was taken from a libtoolized project (I wrote
> the patch), I think I converted all [...] in its ltmain.sh
> to [[...]] when I patched ltmain.m4sh in libtool branch-2-0,
> but I'm not 100% sure as I didn't actually test the result
> (due to the above bootstrap troubles).

I don't understand this paragraph.

> But I'd very much appreciate comments on the general
> approach, so that I know if I should just throw the whole
> thing in the bin now rather than later if I'm way off...

Stuff like cleaning path specs (drive letters etc) should probably be
factored out.

At the moment, I cannot tell you much more yet, but I'd like to thank
you for starting to work on this; it's much needed, and I do realize
that in the end we might have to live with some ugliness in this
respect.

It might be a good idea to collect information about msvc in some
document.

> I configure the libtoolized project with
> 
> .../configure CC="cl -MD" LDFLAGS=-L/msvc/lib
> 
> Where MSYS has a mount so that /msvc points to the MSVC folder
> (typically "C:\Program Files\Microsoft Visual Studio\VC98"
> or something similar)

Yeah, it might be necessary to work around all the `white space in path'
issues as well...

Cheers,
Ralf