Re: Meson build updates - Mailing list pgsql-hackers

Hi,

On 2023-06-09 13:15:27 -0500, Tristan Partin wrote:
> On Fri Jun 9, 2023 at 11:41 AM CDT, Andres Freund wrote:
> > 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.
> 
> I think the savings of not looking up selinux/systemd on non-Linux
> systems is pretty big. Would you accept a change of something like:

For selinux it's default disabled, so it doesn't make a practical
difference. Outside of linux newer versions of meson are more common IME, so
I'm not really worried about it for systemd.


> if meson.version().version_compare('>=0.59')
>   # do old stuff
> else if host_system == 'linux'
>   # do new stuff
> endif
> 
> Otherwise, I am happy to remove the patch.

Hm, I don't quite know how this would end up looking like.


> > > From 189d3ac3d5593ce3e475813e4830a29bb4e96f70 Mon Sep 17 00:00:00 2001
> > > From: Tristan Partin <tristan@neon.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.
> 
> Could you explain more about what costs you foresee?

Repetitive code that needs to be added to each further binary we add. I don't
mind doing that if it has a use case, but I'm not sure I see the use case for
random binaries...


> > > From 5ee13f09e4101904dbc9887bd4844eb5f1cb4fea Mon Sep 17 00:00:00 2001
> > > From: Tristan Partin <tristan@neon.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.
> 
> I felt like this would be the most controversial change. What could be
> done in upstream Meson to make this a more enjoyable experience?

I think *requiring* separate files is a really poor experience when you come
from some other system, where those could trivially be overwritten on the
commandline.

The biggest change to make them more usable would be to properly reconfigure
when the contents of machine file change. IIRC configure is rerun, but the
changes aren't taken into account.


> I do however disagree with the usability of machine files. Could you add a
> little context about what you find unusable about them?

I can quickly change a meson option and run a build and tests. Trivially
scriptable. Whereas with a machine file I need to write code to edit a machine
file, re-configure from scratch, and only then can build / run tests.

It's particularly bad for cross builds, where unfortunately cross files can't
be avoided. It's imo the one area where autoconf beats meson handily.
--host=x86_64-w64-mingw32 works for autoconf. Whereas for meson I need to
manually write a cross file with a bunch of binaries set.

https://github.com/anarazel/postgres/commit/ae53f21d06b4dadf8e6b90df84000fad9a769eaf#diff-3420ebab4f1dbe2ba7102565b0b84e4d6d01fb8b3c1e375bd439eed604e743f8R1

There's some helpers aiming to generate cross files, but I've not been able to
generate something useful for cross compiling to windows, for example.

I've been unable to generate something like referenced in the above commit in
a reasonably concise way with env2mfile.


In the end, I also just don't see a meaningful benefit in forcing the use of
machine files.

Greetings,

Andres Freund