Re: renaming configure.in to configure.ac

On 2020-07-16 18:17, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> I think it'd be a good plan to adopt the beta on master.
> 
>> We already have parts of it backpacked, there have been things we couldn't easily do because of bugs in 2.69. There
aren'tthat many changes to configure it total, and particularly not in the back branches. So I think it'd be ok
overheadwise.
 
> 
> 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.

v1-0001-Rename-configure.in-to-configure.ac.patch

This is unsurprising.

v1-0002-Update-to-Autoconf-2.69b.patch.bz2

This runs auto(re)conf 2.69b and cleans up a minimal amount of obsoleted 
stuff.

The bulk of the changes in the produced configure are from the change 
from echo to printf.  Not much else that's too interesting.  I think a 
lot of the compatibility/testing advisories relate to the way you write 
your configure.ac, not so much to the produced shell code.

v1-0003-Remove-check_decls.m4-obsoleted-by-Autoconf-updat.patch

This is something we had backported and is now no longer necessary. 
Note that there are no significant changes in the produced configure, 
which is good.

v1-0004-configure.ac-Remove-_DARWIN_USE_64_BIT_INODE-hack.patch

This is also something that has been obsoleted.

I'm not immediately aware of anything else that can be removed, cleaned, 
or simplified.

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).

This clearly depends on a lot of specifics of the environment, so some 
more testing would be useful.  This is perhaps something we can 
construct some useful feedback for.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services