Re: renaming configure.in to configure.ac

Hi,

On 2020-07-18 20:15:52 -0400, Tom Lane wrote:
> As best I can tell, the reason it's so slow is that somebody decided they
> ought to have a completionist approach to discovering whether the compiler
> has "C++11 features". The test program embedded in configure for this
> is a good 220 lines long, and it imports 20 different header files, and
> appears to be trying to exercise every one of those modules. This seems
> utterly unreasonable. The traditional autoconf approach, I think, has
> been to test for a couple of bellwether features and assume that if
> you have those then you have the full set. As you say, it'd be
> particularly important to do it like that if the test requires multiple
> iterations to find working switches.

Yea, that's way over top.

> So I think we should push back on that test, or if all else fails
> find a way to dike it out of our configure run --- we don't actually
> care about these feature switches do we?

Not at the moment, at least.

> Also, I'm kinda wondering why our configure script investigates g++
> at all when I haven't specified --with-llvm. Up to now, that hasn't
> been enough of a penalty to really get me irate, but this behavior
> might get me on the warpath about it.

IIRC we ended up doing it that way because it'd be annoying for pgxs
using extensions etc to not be able to rely on the c++ compiler being
detected, even when actually available.

The docs don't mention disabling the conformance tests:

> If necessary, add an option to output variable @code{CXX} to enable
> support for ISO Standard C++ features with extensions. Prefer the
> newest C++ standard that is supported. Currently the newest standard is
> ISO C++11, with ISO C++98 being the previous standard. After calling
> this macro you can check whether the C++ compiler has been set to accept
> Standard C++; if not, the shell variable @code{ac_cv_prog_cxx_stdcxx} is
> set to @samp{no}. If the C++ compiler will not accept C++11, the shell
> variable @code{ac_cv_prog_cxx_cxx11} is set to @samp{no}, and if it will
> not accept C++98, the shell variable @code{ac_cv_prog_cxx_cxx98} is set
> to @samp{no}.

And it can't be cleanly done in the code either afaict:

In lib/autoconf/c.m4
_AC_PROG_CXX_CXX11([ac_prog_cxx_stdcxx=cxx11
ac_cv_prog_cxx_stdcxx=$ac_cv_prog_cxx_cxx11
ac_cv_prog_cxx_cxx98=$ac_cv_prog_cxx_cxx11],
[_AC_PROG_CXX_CXX98([ac_prog_cxx_stdcxx=cxx98
ac_cv_prog_cxx_stdcxx=$ac_cv_prog_cxx_cxx98],
[ac_prog_cxx_stdcxx=no
ac_cv_prog_cxx_stdcxx=no])])

Presumably we could, as a pretty ugly workaround, define the cache
variable to a constant value :/

The commit that added this is

commit bd79b51000e2fe59368c93ff463adb59852ec6e7
Author: Roger Leigh <rleigh(at)debian(dot)org>
Date: 2013-01-20 18:50:49 +0000

AC_PROG_CXX: Add checks for C++11, C++98TR1 and C++98

Greetings,

Andres Freund