Re: Using C++ conditionnally

[Timothée Lecomte]

> Hi Timothée,
>
> * Timothée Lecomte wrote on Tue, May 02, 2006 at 07:06:09AM CEST:
>> >
>> > 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.
>
> AFAIK this issue is present in 2.58 up to current CVS (untested).

Ok, thanks.

>> >> 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.
>
>> 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.
>
> That's not so great.  Automake treats object file names as an internal
> detail, to facilitate compiling the same source file with different
> options (and IIRC also to stand a chance on 8+3 file systems).
>
>> I chose this scheme from the
>> autoconf or automake manual, I don't remember precisely ;-)
>
> I don't think the Automake manual recommends that.

Yes, it does ! I finally find it :

http://sources.redhat.com/automake/automake.html#Conditional-Sources

I am precisely doing what is explained in this page.

> If you can avoid it, don't touch *_DEPENDENCIES, but let Automake
> compute them for you.  Do this instead:
>
> gnuplot_SOURCES = ...normal sources..
> if WANT_WXWIDGETS
> gnuplot_LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o
> $@
> gnuplot_SOURCES += gp_cairo.c ...
> else
> gnuplot_LINK = $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) $(AM_LDFLAGS)
> $(LDFLAGS) -o $@
> endif
>
> If gnuplot is the only program to be linked in this Makefile.am, you can
> get away with
>   CXXLD = @CC@
>
> instead of setting gnuplot_LINK, I guess.
>
> For the Automake conditional to work, put
>   AM_CONDITIONAL([WANT_WXWIDGETS], [test "${enable_wxwidgets_ok}" = yes])
>
> in configure.ac

Ok, I may try it as an alternative.

>
>> > 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 ?
>
> Well, yes, for the code at the moment that looks ok.  I don't want to
> give any guarantees here though since you are munging with internal
> Autoconf details.  Using `cout' without namespace is going to get you in
> trouble though, if you want to be portable to ISO C++ compilers.  (Using
> it with namespace will not work with older compilers, to which I don't
> know whether you want to be portable to them; if yes, look at the
> AC_CXX_NAMESPACES macro provided by the Autoconf Macro Archive.)

Oh, yes, I probably forgot std::cout somewhere... Thanks for reporting that !

>
> Cheers,
> Ralf
>


Best regards,

Timothée