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
