Re: Can't call AC_PROG_CXX conditionally

[Akim Demaille]

 >> Well, if that's the way you want to say it, I can't do anything.  My
 >> opinion is that this is indeed a serious problem, but in itself does
 >> not suffice to throw away Autoconf.  It's been like this since the
 >> very first day of Autoconf.
 Ralf> I don't know. As a matter of fact, with autoconf<=2.52 this seemed to
 Ralf> have worked

``seemed'' is truly the right word.

/tmp % cat configure.in                                           nostromo 9:31
AC_PREREQ(2.13)
AC_INIT
if false; then
  AC_PROG_CC
fi
AC_CHECK_FUNCS(printf exit)
AC_OUTPUT
/tmp % autoconf2.13                                               nostromo 9:33
/tmp % ./configure                                                nostromo 9:33
creating cache ./config.cache
checking for printf... yes
checking for exit... yes
updating cache ./config.cache
creating ./config.status

It `seems' to work, but notice it really didn't try to find a
compiler: there is only the fact that CC *defaults* to cc, which is OK
on my machine.


 Ralf> First of all, I would expect a diagnosis at the time autoconf or
 Ralf> automake is run for cases autoconf/automake can't handle.
 Ralf> At present time, autoconf generates configure scripts that work at
 Ralf> random.

Well, I somewhat disagree with you: the behavior is not pleasant,
yes.  But it is ``random'' when you get out of the lines.  The lines
are: no test should be optional, only decisions.


 >> For instance, what do you expect for
 >> 
 >> AC_INIT
 >> if false; then
 >> AC_PROG_CXX
 >> fi
 >> AC_LANG(C++)
 >> AC_CHECK_FUNCS(foo)
 Ralf> IMO, this is a pathological case.

Ah, OK.  I thought we were addressing this very one.


 Ralf> A typical Makefile using CXX conditionally looks similiar to this:

 Ralf> AC_INIT
 Ralf> AC_ARG_ENABLE(cxx ...)
 Ralf> if enable_cxx
 Ralf> AC_PROG_CXX

Na, OK, we *do* speak about the same.  You just put more flesh around it.

 Ralf> AC_CHECK_<something>
 Ralf> AM_CONDITIONAL( ..., yes)
 Ralf> else
 Ralf> ....
 Ralf> AM_CONDITIONAL(...,no)
 Ralf> fi
 Ralf> AM_CONDITIONAL(....)

 Ralf> In your particular case I would expect one of 3 possibilities:
 Ralf> 1. Autoconf issuing an error "Can't handle this" (c.f. how automake
 Ralf> treats conditional AM_CONDITIONALs)

Doable.  But notice that it is not automake that does it: it's
configure.  We perfectly _can_ have autoconf check that at the end of
configure some precious (maybe *the* precious) variables be defined.

 Ralf> 2. Autoconf to ignore all AC_CHECK_* if CXX is not defined/unset.

Which means we have to remove the default values.  I'm OK with that.

 Ralf> 3. Autoconf to abort if CXX is not defined/set.

Yep.


 >> Or even what you expect for the Makefiles.
 >> 
 >> Autoconf was designed with the fundamental fact that compiler (=
 >> language support) is not an option: it's a must.  Now people want
 >> optional language support; it has to be designed.

 >> It is not at all clear to me that the above example is valid.

 Ralf> Neither to me. But compare it to the example above, or the example I had
 Ralf> attached to my initial report. 

They are the same to me: AC_PROG_CXX, or whatever is AC_REQUIRE'd,
must not be conditionalized, since you might be removing something
someone depends upon.  Actually, maybe that's the key: automate the
runtime checking that any AC_REQUIRE'd macro _was_ run.