Re: Meson build updates

Hi,

On 2023-05-18 10:36:59 -0500, Tristan Partin wrote:
> I took some time to look at the Meson build for Postgres. I contribute
> some of the time to Meson, itself. Within this patchset you will find
> pretty small changes. Most of the commits are attempting to create more
> consistency with the surrounding code. I think there is more that can be
> done to improve the build a bit like including subprojects for optional
> dependencies like lz4, zstd, etc.

Thanks for looking over these!

> From b35ecb2c8dcd71608f98af1e0ec19d965099ceab Mon Sep 17 00:00:00 2001
> From: Tristan Partin <tristan(at)neon(dot)tech>
> Date: Wed, 17 May 2023 09:40:02 -0500
> Subject: [PATCH postgres v1 12/17] Make finding pkg-config(python3) more
> robust
>
> It is a possibility that the installation can't be found. Checking for
> Python.h is redundant with what Meson does internally.

That's not what I saw - we had cases where Python.h was missing, but the
python dependency was found. It's possible that this is dependent on the
meson version.

> From 47394ffd113d4170e955bc033841cb7e18fd3ac4 Mon Sep 17 00:00:00 2001
> From: Tristan Partin <tristan(at)neon(dot)tech>
> Date: Wed, 17 May 2023 09:44:49 -0500
> Subject: [PATCH postgres v1 14/17] Reduce branching on Meson version
>
> This code had a branch depending on Meson version. Instead, we can just
> move the system checks to the if statement. I believe this also keeps
> selinux and systemd from being looked for on non-Linux systems when
> using Meson < 0.59. Before they would be checked, but obviously fail.

I like the current version better - depending on the meson version makes it
easy to find what needs to be removed when we upgrade the meson minimum
version.

> From 189d3ac3d5593ce3e475813e4830a29bb4e96f70 Mon Sep 17 00:00:00 2001
> From: Tristan Partin <tristan(at)neon(dot)tech>
> Date: Wed, 17 May 2023 10:36:52 -0500
> Subject: [PATCH postgres v1 16/17] Add Meson overrides
>
> 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 = libpq
>
> Then 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.
>
> I have also added overrides for the various public-facing exectuables.
> Though I don't expect them to get much usage, might as well go ahead and
> override them. They can be used by adding the following line to the
> aforementioned wrap file:

I think adding more boilerplate to all these places does have some cost. So
I'm not really convinced this is worth doign.

> From 5ee13f09e4101904dbc9887bd4844eb5f1cb4fea Mon Sep 17 00:00:00 2001
> From: Tristan Partin <tristan(at)neon(dot)tech>
> Date: Wed, 17 May 2023 10:54:53 -0500
> Subject: [PATCH postgres v1 17/17] Remove Meson program options for specifying
> paths
>
> Meson has a built-in way to override paths without polluting project
> build options called machine files.

I think meson machine files are just about unusable. For one, you can't
actually change any of the options without creating a new build dir. For
another, it's not something that easily can be done on the commandline.

So I really don't want to remove these options.

Greetings,

Andres Freund