On 2013-03-15 21:18, Zack Weinberg wrote: > On 2013-03-15 9:14 AM, Peter Rosin wrote: > >> I just wanted to chime in with the fact that it's working just fine to >> use one of said UNIX-like portability environments and have Autoconf >> probe MSVC directly. > > This is relevant to my interests ;) How do you smooth over the > differences in command line interface between 'cc' and 'cl'? The 'compile' script from (modern) Automake is good enough and 'depcomp' has modes to support MSVC. There is also the 'ar-lib' script from the same source that wraps lib.exe to support basic archival operations in much the same manner. > (Can you make it work in the presence of libtool?) Yes, libtool with MSVC in MSYS (or in Cygwin, but that is more alien) works just fine. I tend to use something like this: .../configure \ CC=cl \ CFLAGS=-MD \ CXX=cl \ CXXFLAGS=-MD \ LD=link \ NM="dumpbin -symbols -headers" \ AR=lib \ STRIP=: \ RANLIB=: It the package doesn't have AM_PROG_CC_C_O in its configure.ac it might be needed to say CC="/path/to/compile cl", and sometimes it might be good to say CC="cl -nologo" (since the "logo" boilerplate is dumped on stderr and any output on stderr from the compiler is suspect). Similarly for AR=lib vs AR="/path/to/ar-lib lib" if the package doesn't have AM_PROG_AR. Libtool knows about using dumpbin as symbol lister, but if the build uses $NM directly from some Makefile (or otherwise) it gets tougher, as the wrapper is implemented "internally" in libtool. Cheers, Peter _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
