> > 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.
Sorry for the confusion. Our makefiles do use -Tp and support C++
extensions cc, cpp and cxx. (BTW, df needs either .for file extension
or -Tf/-TF option.)
However, our system knows a lot about the compilers and the system -- it
effectively does a bit more than libtool and automake do together (I
haven't looked at the recent development versions though). I wanted to
limit how much information is passed to autoconf. Currently that
amounts to CXX, CXXCPP, CXXCPPFLAGS, CXXFLAGS, CXXLIBS and CXXLDFLAGS;
ditto for C and F77. The modified autoconf macros discover need of -Fo
and file extension. I decided to not communicate extravagancies of how
to invoke the compiler, and just get the minimum done: detect what
headers are available and do some language feature tests -- but not what
libraries can be linked.
(Apropos: autoconf should be able to keep the LIBS and LDFLAGS for
different languages separate. I am not sure it should do it by default,
but it should be possible.)
> 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.
Yes, probably. I don't know how far you want to go. You will quickly
find that you are teaching considerable compiler knowledge to autoconf,
or even think of merging autoconf and automake/libtool. IMHO, not worth
it. Our build system is moving towards wrapping compilers instead of
trying to teach all the complexity to autoconf (and make!).
> I don't think we are really interested in hacks.
I did what was required to get it to work, though it is quite possible
you won't like the way I did it :-) It wasn't desperately unclean, I
did try to wrap the existing autoconf macros where I could instead of
redefining them directly.
FWIW, the changes I made are:
- Dynamically choose the C++ extension and `-o' option; done by
trying to run $CXX (without -nologo) to see if it is MSVC++
- Using languange-specific variables (see above)
- In 2.13 (2.12?), AC_PROG_CXXCPP had a bug in that if `$CXXCPP'
was set, it got nuked instead of getting used. This happens
because it assigns value to `CXXCPP' from `ac_cv_prog_CXXCPP',
but only sets the latter if the former was empty...
I never made executable linking work under autoconf. It would need
`-Fe' to name the executable, not `-o'. So with my changes, no chance
to test if some library/function is available, but compilation tests
work.
> 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.
Good!
> I have little trust in M$, but I still hope that M$VC is not that dumb.
> Let's check it.
...> cl -E foo.c > nul
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for
80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
foo.c
foo.c(1) : fatal error C1083: Cannot open include file: 'nonexistent.h':
No such file or directory
...> echo %errorlevel%
2
...> cl -E -TP foo.cc >nul
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for
80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
foo.cc
foo.cc(1) : fatal error C1083: Cannot open include file:
'nonexistent.h': No such file or directory
...> echo %errorlevel%
2
> I want to see what "echo %errorlevel%" prints. If it's not 0, your problem
> must already have been solved in the CVS Autoconf.
Good! Looks like that.
> 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.
Define sane :-) In addition to -Tp, -Fo, -Fe etc., we use these for cl:
-GF -GR -EHsc -QI0f -W3 -G5 -MD
-GF pools strings into read-only memory
-GR enables RTTI
-EHsc tells to use synchronous exceptions and that
extern "C" functions will not throw
-QI0f is a workaround for Pentium processor bug
-W3 is warning level 3
-G5 tells to generate code for Pentium and higher
-MD tells what threading/run-time library mode to use
(multi-threaded, run-time libs in dlls)
Others are added according to what the developer requests for
optimisation or debugging (-Zi, -Od, -Ot, -Ox).
Of these, looks like an average C++ programmer would like to have at
least -GR and -EHsc (latter equivalent to -GX). Default is no exception
handling, no rtti.
> If this is true, it must be really bad.
What needs to happen is that commands like:
c++ -c foo.cxx -o foo.o
c++ -o foo foo.o -L/some/where -lbar
must become:
cl -c -Tpfoo.cxx -Fofoo.obj
cl -Fefoo.exe foo.obj bar.lib -link -LIBPATH:\some\where
(`cygpath -w -- /some/where' will translate paths under cygwin.)
BTW, -LD has its own meaning (create DLL). Got around that one with the
convention of using /LD and -L (leading slash versus leading dash).
-Wl,<stuff> allows our packages to differentiate between options that
must come before and after `-link', sort of the same way -Wl works under
many unix systems. Yummy.
> 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 :-)
Quite true. Our build system's makefiles have a fair amount of smarts,
know a good deal about the underlying tools, and invoke native tools
without wrappers. I am in the process of changing that so that autoconf
and make will not know about the compilers directly. Too much grief...
Hope this helps and many thanks for the effort you are putting into
this!
//lat
--
If an experiment works, something has gone wrong.
