Re: autoconf + automake support for MSVC

[Peter Rosin]

Den 2011-09-02 23:11 skrev Bruno Haible:
> Ralf Wildenhues wrote in
> <http://lists.gnu.org/archive/html/bug-gnulib/2011-08/msg00236.html>:
>>>> Windows+MSVC. I know this is not a gnulib target.
>>>
>>> Yes. But it could become a gnulib target if the $CC wrapper script was 
>>> agreed
>>> upon in GNU. For example, if Automake would distribute it, like it 
>>> distributes
>>> a couple of other wrapper scripts.
>>
>> There is a branch in the Automake git repo which has that.
>> Unfortunately, my lack of time has contributed to it not being actively
>> merged and maintained.
> 
> This branch contains an 'ar' emulation (file 'ar-lib'). Good.
> But how is the file 'compile' meant to be used? CC="compile cl"
> or how? In other words, if I set CC="cl", how are autoconf tests
> that run the compiler meant to be performed?
> 
> People routinely use a program called 'cccl' in
>   $ ./configure CC=cccl
> See [1].
> 
> Will that functionality be moved from 'compile' to a script like
> 'cccl' at some point?

The web has a couple of different forked versions of cccl. What is
the "upstream" for that script? There is ancient support for some
version of cccl in libtool, but I didn't get it to work with any
version of cccl that I found (some things might have worked, but
there were loads of failures for simple things in the libtool
testsuites. I have forgotten the details so don't ask...). So, I
didn't want to create yet another fork of cccl, and instead fixed
the 'compile' script in Automake to handle the bits that must be
handled by the build tools (and taught libtool to deal with cl
natively). What I didn't do was add all sorts of options to
'compile' to make cl look like gcc, because that way lies madness.
Packages aiming for portability shouldn't assume gcc in the first
place. End result, you have to feed optimization options and such
in the way cl expects them.

There is also the 'ar-lib' script that does the bare minimum to
present a posixy archiver interface (albeit incomplete) to Microsoft
lib, in a similar manner that 'compile' makes cl understand the
-l and -L options (and a few others).

All in all, I regularly use these scripts to build packages with
cl, and the configure.ac/Makefile.am of those packages need not
do special things to have it all work.

A typical configure invocation might be (from an MSYS shell):

.../configure CC="cl -nologo" CFLAGS=-MD LD=link NM="dumpbin -symbols" \
  AR="/home/peda/automake/lib/ar-lib lib" STRIP=: RANLIB=: \
  --enable-dependency-tracking

configure.ac needs to have AM_PROG_CC_C_O which might not be one of
the most common macros, but that's certainly not too bad. And when
the mentioned branch in Automake git is merged I imagine there will be
a macro named something like AM_PROG_AR that will make it sufficient
to say AR=lib to configure, instead of pointing at 'ar-lib' explicitly.

I don't think cccl is the future, I see it as the past. It's
simply not needed when the needed bits are already in 'compile'.

It's a bit sad to see all the effort going into writing private
scripts wrapping cl into something that looks like gcc, when the
effort could be spent making autotools just work instead.

Cheers,
Peter