Hi Ralf,
Thank you for your fast and detailed answer.
> 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:
And in which version does this bug occur ? Currently the gnuplot
configure.in asks for 2.58 at least.
> 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.
I understand, and as soon as the painful side has a possible alternative
not to get stucked, it's ok for me.
>> 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.
You are right, the C++ files are listed in EXTRA_gnuplot_SOURCES, and the
corresponding object files are placed in gnuplot_DEPENDENCIES when the
feature is enabled in the configure script. I chose this scheme from the
autoconf or automake manual, I don't remember precisely ;-)
src/Makefile.am contains the following lines :
gnuplot_DEPENDENCIES = $(WX_OBJ)
EXTRA_gnuplot_SOURCES = (...) gp_cairo.c wxt_gui.cpp
and configure.in contains :
if test "${enable_wxwidgets_ok}" = yes
then
(...)
WX_OBJ='wxterminal/wxt_gui.$(OBJEXT) wxterminal/gp_cairo.$(OBJEXT)'
AC_SUBST([WX_OBJ])
fi
And my automake version is 1.9.6
When it comes to using _LINK, I am not sure I like this solution, because
I am then obliged to take care of all the flags...
>> 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.
So, to make something more waterproof, I could try :
m4_pushdef([AC_MSG_ERROR], [cxx_error=yes])
AC_PROG_CXX
AC_LANG_PUSH([C++])
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[const char hw[] = "Hello, World\n";]],
[[cout << hw;]])],
[AC_PROG_CXXCPP
cxx_error=no],
[cxx_error=yes])
AC_LANG_POP([C++])
m4_popdef([AC_MSG_ERROR])
So that if any error occur during with the c++ compiler, cxx_error is
defined to "no" and I can do tests on it. Is it correct ?
Thanks. Regards,
Timothée
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
