Обсуждение: Migrate to autoconf 2.72?
Hi Hackers, I wanted to add “—enable-shadows-warning” to “./configure”, I updated configure.ac, then installed autoconf on my MacBook,then when I tried to run autoconf, I got an error: ``` % autoconf configure.ac:22: error: Autoconf version 2.69 is required. Untested combinations of 'autoconf' and PostgreSQL versions are not recommended. You can remove the check from 'configure.ac' but it is then your responsibility whether the result works or not. configure.ac:22: the top level autom4te: error: /opt/homebrew/opt/m4/bin/m4 failed with exit status: 1 ``` I saw my newly installed autoconf is version 2.72. Then I tried to install autoconf 2.69, it says 2.69 is dead now: ``` ==> Fetching downloads for: autoconf@2.69 Error: autoconf@2.69 has been disabled because it is a versioned formula! It was disabled on 2024-12-14. ``` Then I tried to disable the version check, and got the other error: ``` % autoconf configure.ac:1290: warning: $as_echo is obsolete; use AS_ECHO(["message"]) instead lib/m4sugar/m4sh.m4:690: _AS_IF_ELSE is expanded from... lib/m4sugar/m4sh.m4:697: AS_IF is expanded from... ./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from... ./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from... config/ax_pthread.m4:88: AX_PTHREAD is expanded from... lib/m4sugar/m4sh.m4:697: AS_IF is expanded from... configure.ac:1290: the top level ``` Looks like some efforts have to be made to upgrade to autoconf 2.72 (or another version), which is not a task I have confidentto take. So I’m just reporting the problem, hope someone can take care of it. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
On Fri, Nov 28, 2025 at 9:35 AM Chao Li <li.evan.chao@gmail.com> wrote: > > Hi Hackers, > > I wanted to add “—enable-shadows-warning” to “./configure”, I updated configure.ac, then installed autoconf on my MacBook,then when I tried to run autoconf, I got an error: > > ``` > % autoconf > configure.ac:22: error: Autoconf version 2.69 is required. > Untested combinations of 'autoconf' and PostgreSQL versions are not > recommended. You can remove the check from 'configure.ac' but it is then > your responsibility whether the result works or not. > configure.ac:22: the top level > autom4te: error: /opt/homebrew/opt/m4/bin/m4 failed with exit status: 1 > ``` > > I saw my newly installed autoconf is version 2.72. Then I tried to install autoconf 2.69, it says 2.69 is dead now: > ``` > ==> Fetching downloads for: autoconf@2.69 > Error: autoconf@2.69 has been disabled because it is a versioned formula! It was disabled on 2024-12-14. > ``` Outside the main $thread question or updating on MacOS, I usually just grab https://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz and ./configure && make install and it should work (and it's really tiny and compiles in like 500ms). -J.
> On Nov 28, 2025, at 17:02, Jakub Wartak <jakub.wartak@enterprisedb.com> wrote: > > Outside the main $thread question or updating on MacOS, I usually just > grab https://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz and > ./configure && make install and it should work (and it's really tiny > and compiles in like 500ms). > > -J. Wow, so easy to get autoconf 2.69 installed on my MacBook. Thank you, Jakub. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
On 28.11.25 09:34, Chao Li wrote: > Looks like some efforts have to be made to upgrade to autoconf 2.72 (or another version), which is not a task I have confidentto take. So I’m just reporting the problem, hope someone can take care of it. See also here: https://www.postgresql.org/message-id/flat/1627398.1642955357%40sss.pgh.pa.us
Hi hackers, Quick and somewhat related question: if Meson support was added in PG 16, does this mean that Autotools will be supported up to and including PG 20? -- Best regards, Aleksander Alekseev
On 01.12.25 09:47, Aleksander Alekseev wrote: > Quick and somewhat related question: if Meson support was added in PG > 16, does this mean that Autotools will be supported up to and > including PG 20? No, there is currently no agreed schedule for this.
po 1. 12. 2025 v 11:06 odesílatel Peter Eisentraut <peter@eisentraut.org> napsal:
On 01.12.25 09:47, Aleksander Alekseev wrote:
> Quick and somewhat related question: if Meson support was added in PG
> 16, does this mean that Autotools will be supported up to and
> including PG 20?
No, there is currently no agreed schedule for this.
almost all extensions has not meson support still
Regards
Pavel
Hi Pavel, >> No, there is currently no agreed schedule for this. > > almost all extensions has not meson support still Extensions shouldn't necessarily be built using the same build system as the PG core. I can build PG using Meson and then install a 3rd party extension using `make install && make installcheck`. In other words, we can stop supporting Autotools for building the core without affecting extensions. Unless I'm missing something, of course. -- Best regards, Aleksander Alekseev
po 1. 12. 2025 v 11:42 odesílatel Aleksander Alekseev <aleksander@tigerdata.com> napsal:
Hi Pavel,
>> No, there is currently no agreed schedule for this.
>
> almost all extensions has not meson support still
Extensions shouldn't necessarily be built using the same build system
as the PG core. I can build PG using Meson and then install a 3rd
party extension using `make install && make installcheck`. In other
words, we can stop supporting Autotools for building the core without
affecting extensions. Unless I'm missing something, of course.
But when you use autotools for extensions, then you still should to maintain it.
--
Best regards,
Aleksander Alekseev
Hi Pavel, > But when you use autotools for extensions, then you still should to maintain it. True, but the problem can be decomposed into two parts - maintaining for the core and maintaining for the extensions. At least core developers won't have to check if another patch compiles with Autotools. I'm not certain what to do with the extensions. It seems that as long as we maintain Autotools the authors will have little interest in switching to Meson (or other build system - TimescaleDB for instance uses CMake; many modern extensions seem to be written in Rust with its own build system). Apparently we will have to start showing warnings at some point, and then finally drop Autotools. Unless we want to maintain it forever. This being said, I didn't investigate how much effort it will take to keep maintaining Autotools for extensions. -- Best regards, Aleksander Alekseev
po 1. 12. 2025 v 12:48 odesílatel Aleksander Alekseev <aleksander@tigerdata.com> napsal:
Hi Pavel,
> But when you use autotools for extensions, then you still should to maintain it.
True, but the problem can be decomposed into two parts - maintaining
for the core and maintaining for the extensions. At least core
developers won't have to check if another patch compiles with
Autotools.
Almost all server headers can be used in any extension. So I don't think maintaining autotools for extensions can be easier than maintaining autotools for the server.
I'm not certain what to do with the extensions. It seems that as long
as we maintain Autotools the authors will have little interest in
switching to Meson (or other build system - TimescaleDB for instance
uses CMake; many modern extensions seem to be written in Rust with its
own build system). Apparently we will have to start showing warnings
at some point, and then finally drop Autotools. Unless we want to
maintain it forever.
This being said, I didn't investigate how much effsqlort it will take to
keep maintaining Autotools for extensions.
I support Meson in my extensions - Orafce and plpgsql_check, but unfortunately it is harder to write and harder to maintain meson.build than Makefile for pgxs
I am not sure if there are some authorities who specified some generic template of meson.build for extensions.
Maybe with some Postgres Meson's extension for building postgres's extension then writing meson.build can be more easy than it is now - but now, there is zero support for meson for extension from Postgres side.
Regards
Pavel
--
Best regards,
Aleksander Alekseev
Hi, > I am not sure if there are some authorities who specified some generic template of meson.build for extensions. > [...] > but now, there is zero support for meson for extension from Postgres side. contrib/*/meson.build seem quite generic and quite supported. Or perhaps I don't quite understand the complexity you mentioned? Maybe you could give a particular example? -- Best regards, Aleksander Alekseev
po 1. 12. 2025 v 13:45 odesílatel Aleksander Alekseev <aleksander@tigerdata.com> napsal:
Hi,
> I am not sure if there are some authorities who specified some generic template of meson.build for extensions.
> [...]
> but now, there is zero support for meson for extension from Postgres side.
contrib/*/meson.build seem quite generic and quite supported.
Or perhaps I don't quite understand the complexity you mentioned?
Maybe you could give a particular example?
you can try to compare https://github.com/okbob/plpgsql_check/blob/master/meson.build
versus
The meson does one target more in this case, so these files are not 100% comparable - maybe at 75%, but still - for Make, I have almost all logic in include $(PGXS)
--
Best regards,
Aleksander Alekseev