Re: renaming configure.in to configure.ac

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 2020-07-16 18:17, Tom Lane wrote:
>> Yeah. Because we'd want to rip out those hacks, it's not quite as simple
>> as "regenerate configure with this other autoconf version"; somebody will
>> have to do some preliminary investigation and produce a patch for the
>> autoconf input files. Peter, were you intending to do that?

> Okay, let's take a look. Attached is a patch series.

I haven't carefully read any of these patches, but I applied them and did
some testing on a couple of machines. I find that I get near-identical
output files, so the functionality appears OK. There are just a couple of
non-comment differences in pg_config.h:

1. The new autoconf omits
#define HAVE_MEMORY_H 1
which we don't care about, so that's not an issue.

2. "pg_restrict" and "restrict" get defined as "__restrict__" not
"__restrict". That seems cosmetic.

> One thing that's annoying is that the release notes claim that configure
> should now be faster, and some of the changes they have made should
> support that, but my (limited) testing doesn't bear that out. Most
> notably, the newly arisen test
> checking for g++ option to enable C++11 features... none needed
> takes approximately 10 seconds(!) on my machine (for one loop, since
> "none needed"; good luck if you need more than none).

Yeah, I confirm these results. The time penalty for the "C++11 features"
test is about 8 seconds on my RHEL8 machine, but only about 3 seconds
on a current MacBook Pro. Not sure if that's all about faster hardware
or if clang is faster than gcc for this test.

Now, the one bit of good news about that is that the result is cacheable:
using either ccache or configure --enable-cache causes the time for a
repeated test to drop to nil. Still, it's going to be damn annoying for
environments where neither escape hatch applies.

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.

BTW, when I tried this on an old gcc (gaur's compiler), the C++11 test
failed fairly quickly but then it spent an equally ridiculous amount of
time testing for "C++98 features". So both parts of that are completely
overdesigned if you ask me.

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?

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.

Anyway, the bottom line for speed is that on a modern Linux (RHEL8),
considering only the runtime in the fully-cached case (both ccache and
accache up to date), it does seem like the new version is noticeably
faster: I see ~2.2 seconds instead of 2.7. Similarly on my MacBook Pro.
It's hard to compare the non-cached cases because the silly g++ test
swamps everything.

> This clearly depends on a lot of specifics of the environment, so some
> more testing would be useful.

The test scenarios I tried were

* gcc 8.3.1 on RHEL8
* Apple clang version 11.0.3 on macOS Catalina
* gcc 4.5.4 on HPUX 10.20

regards, tom lane