Casual Meson fixups
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t48393psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 12:12 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t48393_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t48393_1 && git checkout t48393_1Patchset v1 (message #1) is on t48393_1
The first two patches in the series are re-proposals that had previously
been approved[0] by Andres, but fell through the cracks.
The only patch that _could_ be controversial is probably the last one,
but from my understanding it would match up with the autotools build.
One thing that I did notice while testing this patch is that Muon
doesn't build postgres without coercing the build a bit. I had to
disable nls and plpython. The nls issue could be fixed with a bump to
Meson 0.59, which introduces import(required:). nls isn't supported in
Muon unfortunately at the moment. The plpython issue is that it doesn't
understand pymod.find_installation(required:), which is a bug in Muon.
Muon development has slowed quite a bit this year. Postgres is probably
the largest project which tries its best to support Muon. It seems like
if we want to keep supporting Muon, we should get a buildfarm machine to
use it instead of Meson to catch regressions. OR we should contemplate
removing support for it.
Alternatively someone (me?) could step up and provide some patches to
Muon to make the postgres experience better. But I wonder if any
Postgres user even uses Muon to build it.
--
Tristan Partin
Neon (https://neon.tech)
Attachments:
t48393_1v1-0002-Add-Meson-override-for-libpq.patchtext/x-patch; charset=utf-8; name=v1-0002-Add-Meson-override-for-libpq.patchDownload+2-1
v1-0007-Disable-building-contrib-targets-by-default.patchtext/x-patch; charset=utf-8; name=v1-0007-Disable-building-contrib-targets-by-default.patchDownload+5-4
v1-0001-Make-finding-pkg-config-python3-more-robust.patchtext/x-patch; charset=utf-8; name=v1-0001-Make-finding-pkg-config-python3-more-robust.patchDownload+7-6
v1-0005-Use-the-meson-compat-layer-for-muon.patchtext/x-patch; charset=utf-8; name=v1-0005-Use-the-meson-compat-layer-for-muon.patchDownload+5-5
v1-0004-Tackle-a-FIXME-in-Meson-comment.patchtext/x-patch; charset=utf-8; name=v1-0004-Tackle-a-FIXME-in-Meson-comment.patchDownload+12-13
v1-0006-Make-use-of-find_program-meson.patchtext/x-patch; charset=utf-8; name=v1-0006-Make-use-of-find_program-meson.patchDownload+38-36
v1-0003-Fix-grammar-in-Meson-comment.patchtext/x-patch; charset=utf-8; name=v1-0003-Fix-grammar-in-Meson-comment.patchDownload+1-2
Hi,
On 2023-09-01 11:31:07 -0500, Tristan Partin wrote:
Muon development has slowed quite a bit this year. Postgres is probably the
largest project which tries its best to support Muon. It seems like if we
want to keep supporting Muon, we should get a buildfarm machine to use it
instead of Meson to catch regressions. OR we should contemplate removing
support for it.
I found it to be quite useful to find bugs in the meson.build files...
Subject: [PATCH v1 2/7] Add Meson override for libpq
Meson has the ability to do transparent overrides when projects are used
as subprojects. For instance, say I am building a Postgres extension. I
can define Postgres to be a subproject of my extension given the
following wrap file:[wrap-git]
url = https://git.postgresql.org/git/postgresql.git
revision = master
depth = 1[provide]
dependency_names = libpqThen in my extension (root project), I can have the following line
snippet:libpq = dependency('libpq')
This will tell Meson to transparently compile libpq prior to it
compiling my extension (because I depend on libpq) if libpq isn't found
on the host system.
---
src/interfaces/libpq/meson.build | 2 ++
1 file changed, 2 insertions(+)
This example doesn't seem convincing, because if you build a postgres
extension, you need postgres' headers - which makes it extremely likely that
libpq is available :)
From 5455426c9944ff8c8694db46929eaa37e03d907f Mon Sep 17 00:00:00 2001
From: Tristan Partin <tristan@neon.tech>
Date: Fri, 1 Sep 2023 11:07:40 -0500
Subject: [PATCH v1 7/7] Disable building contrib targets by defaultThis matches the autotools build.
Why should we match it here? IIRC this would actually break running meson
install, because it doesn't grok targets that are installed but not built by
default :/.
Greetings,
Andres Freund
On 2023-10-22 Su 20:59, Andres Freund wrote:
Hi,
On 2023-09-01 11:31:07 -0500, Tristan Partin wrote:
Muon development has slowed quite a bit this year. Postgres is probably the
largest project which tries its best to support Muon. It seems like if we
want to keep supporting Muon, we should get a buildfarm machine to use it
instead of Meson to catch regressions. OR we should contemplate removing
support for it.I found it to be quite useful to find bugs in the meson.build files...
I agree with Tristan that if we are going to use it then we should have
a buildfarm animal that does too.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com