Re: Using C++ conditionnally

[Ralf Wildenhues]

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!)