Thread: Casual Meson fixups

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)

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 = 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.
> ---
>  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 default
> 
> This 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