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