Hello, Lassi!
> > I believe that -TP should fix the problem, but I cannot test it.
> > Set CXX='cl -TP' and check if the tests work better.
>
> I haven't tested this under autoconf, but -TP (or -Tpfile.cc) works
> under make in cygwin. That was some time ago (maybe a year or so) with
> MSVC++ 5.x. My solution was to not use the option but to hack the
> autoconf file extension macros to switch to `cpp' if it detected `cl'.
But we are looking for a clean solution. If the project is for UNIX it is
likely to use .cc for C++. You would have to rename the sources too, not
only hack Autoconf.
There is a macro AC_PROG_CC_STDC. It adds some flags to the C compiler so
that it accepts ANSI C. It looks like that we need a similar macro for C++
that ensures that the compiler accepts C++ properly (and defines
__cplusplus), without tricks with extentions.
> But that was just the tip of the ice-berg... So while I am at it, a few
> more things worth a mention.
This is quite frustrating, but Autoconf should go its part of the way.
> MSVC++ always prints the file name out when compiling a file. I seem to
> recall this confused the autoconf macros that tried to detect whether
> the compile was spitting out error messages or not. I think I hacked
> the macros to not care about lines with just the file name (MSVC++
> doesn't print a colon) when looking for errors. I haven't looked
> closely at the recently proposed changes, but they might do the right
> thing. Should I post my hacked up autoconf macros?
I don't think we are really interested in hacks.
I hope that the issue has been fixed. Now Autoconf checks warnings only
from very dumb compilers that don't indicate missing includes with the
exit status.
I have little trust in M$, but I still hope that M$VC is not that dumb.
Let's check it.
Please create test.c with only one line
#include <nonexistent.h>
and run
cl -E test.c >nul
echo %errorlevel%
copy test.c test.cc
cl -E -TP test.cc >nul
echo %errorlevel%
I want to see what "echo %errorlevel%" prints. If it's not 0, your problem
must already have been solved in the CVS Autoconf.
> You'll probably want to compile with `cl -nologo' (at least with MSVC++
> 5.x and below, haven't tried with 6.x yet). Otherwise you will get a
> banner that might be very confusing to the error message guessing logic
> :-)
I hope it is no longer confusing.
On the other side, as I said before, we need a generic version of
AC_PROG_CC_STDC that adjusts flags not only for C and not only for
accepting ANSI C, but strives to make the compiler as sane as possible,
but without overriding the options from the user.
> Depending on how extensively you want to support `cl', there are many
> more issues to deal with -- sometimes convoluted ones. Like it doesn't
> understand `-l' or `-L' options, so anything that looks for symbols by
> linking will probably fail.
If this is true, it must be really bad.
> Similar observations go for the `df' FORTRAN compiler. It doesn't even
> want to see any `/' characters in file names, they have to be '\' :-)
> It doesn't understand most common unix compiler options either, so
> FORTRAN-compiling packages will probably choke if they try anything
> non-trivial.
>
> And since this is probably under cygwin, it might be worth mentioning
> that `cl' and `df' (or `link' or `lib' or any other native tool) do not
> understand cygwin's filesystem mounts or symlinks. All paths for -I and
> -L options must be translated to real windows paths before invoking the
> tools -- including relative ones as they might be symlinks!
Well, Autoconf cannot solve all the problems alone. You may need a
wrapper, such as the fake C compiler coming with the MKS toolkit. You may
want an open-source wrapper too :-)
Regards,
Pavel Roskin
