> 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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf