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