[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using C++ conditionnally
From: |
Ralf Wildenhues |
Subject: |
Re: Using C++ conditionnally |
Date: |
Tue, 2 May 2006 03:27:05 +0200 |
User-agent: |
Mutt/1.5.11+cvs20060403 |
Hi Timothée,
Your report touches several issues:
* Timothée Lecomte wrote on Tue, May 02, 2006 at 02:44:54AM CEST:
>
> I had to add AC_PROG_CXX and AC_PROG_CXXCPP to the configure.in file. As
> many of you may know, they should not be called conditionally, so the
> script do call them unconditionally.
>
> But, of course, users should still be able to compile gnuplot if they
> don't have any C++ compiler. In this case, the macro AC_PROG_CXX does not
> fail, but sets by default CXX to g++, even if it is not present,
This the bug that the second AC_PROG_C* invocation won't fail:
http://lists.gnu.org/archive/html/autoconf/2006-03/msg00067.html
and I already argued here:
http://lists.gnu.org/archive/html/autoconf/2006-04/msg00008.html
that it should be fixed, but that it's a bit dangerous to do now.
Together with that fix, also a method should be provided to keep
the configure script running in case any of AC_PROG_CC/CXX/F77..
fail; packages like yours and Libtool need this additional
functionality, otherwise configure would just fail for users without
a C++ compiler. [1]
Erm, in fact, the documentation does not even state that any of those
macros _would_ fail when they fail to find a suitable compiler;
AC_PROG_CXX is even documented as:
| Otherwise, if the macro is invoked without an argument, then
| search for a C++ compiler under the likely names (first `g++' and
| `c++' then other names). If none of those checks succeed, then as
| a last resort set `CXX' to `g++'.
So really this is a very unfortunate situation: we have conflicting
expectations as to the correct behavior of the plain macros we have
at the moment, and real-world usage in all cases (due to the bug that
ordering matters at the moment), and documentation (that states that
AC_PROG_CXX won't exit), so fixing this is going to be painful for at
least one side.
> so that
> automake will finally think that the project contains some C++ files, and
> use g++ to link the object files. .... And there it fails.
Wait; I don't see why this happens. If you list only C files for a
program, it won't use the C++ driver for linking. But you may be using
Automake conditionals to add C++-compiled objects or so; then Automake
does not stand a chance to decide at Automake time. However, even then
you should be able to fix this by setting the per-target linker; search
for maude_LINK in
info Automake "Program and Library Variables"
If in doubt, show parts of your Makefile.am so we can find out why
Automake (which version BTW?) chooses CXXLINK.
> So I did the following :
> dnl wxWidgets terminal needs C++
> dnl These tests cannot be called conditionally.
> dnl However, even if there is no C++ compiler on the system,
> dnl autoconf will set CXX as g++ : this must be reverted.
> AC_PROG_CXX
> AC_PROG_CXXCPP
> Can you comment on this, and tell me if it is sure enough ? It works for
> me (autoconf 2.59, I tried it by renaming g++ and c++ to somethings else),
> but I would like to be sure that it will work on future autoconf versions.
It looks ok for Autoconf-2.59 and CVS as of now, if the AC_PROG_CXX
comes after AC_PROG_CC, but depending on how above issues will be fixed,
this may need to be revisited.
Cheers,
Ralf
[1] CVS Libtool uses
pushdef([AC_MSG_ERROR], [_lt_caught_CXX_error=yes])
AC_PROG_CXX
if test -n "$CXX" && ( test "X$CXX" != "Xno" &&
( (test "X$CXX" = "Xg++" && `g++ -v >/dev/null 2>&1` ) ||
(test "X$CXX" != "Xg++"))) ; then
AC_PROG_CXXCPP
else
_lt_caught_CXX_error=yes
fi
popdef([AC_MSG_ERROR])
to get around this, but that's very ugly, and should be fixed as soon as
Autoconf is fixed; besides the fact that it should use m4_pushdef instead
of pushdef (2 instances), and
(g++ -v) >/dev/null 2>&1
instead of
g++ -v >/dev/null 2>&1
(And if you use it in your own code, be sure to rename the variable from
Libtool's name space!)