Horton

Re: Meson build updates

Tristan Partin <tristan@neon.tech>

View thread View on postgr.es
From: "Tristan Partin" <tristan@neon.tech>
To: "Andres Freund" <andres@anarazel.de>
Cc: <pgsql-hackers@postgresql.org>
Date: 2023-06-13T19:56:36Z
Lists: pgsql-hackers 
On Fri Jun 9, 2023 at 1:36 PM CDT, Andres Freund wrote:
> On 2023-06-09 13:15:27 -0500, Tristan Partin wrote:
> > On Fri Jun 9, 2023 at 11:41 AM CDT, Andres Freund wrote:
> > > > 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...

I was thinking today. When you initially wrote the build, did you try
using the src/bin/meson.build file as the place where all the binaries
were built? As you say, most of the src/bin/xxx/meson.build files are
extrememly reptitive.

We had a similar-ish issue in my last project which I solved like:

https://github.com/hse-project/hse/blob/master/tools/meson.build#L20-L405

This is a pattern I used quite frequently in that project. One benefit
of this approach is that the binaries all end up next to each other in
the build tree which is eventually how they'll be laid out in the
install destination. The other benefit is of course reducing reptitive
code.

- ./build/src/bin/psql/psql
+ ./build/src/bin/psql

Let me know what you think.

-- 
Tristan Partin
Neon (https://neon.tech)

Commits

  1. meson: Make detection of python more robust

  2. meson: Pass more feature option through to required kwargs

  3. meson: Tie adding C++ support to the llvm Meson option

  4. meson: Fix intl misspelling

  5. meson: Use a better error message in an impossible case

  6. meson: Make some Meson style more consistent with surrounding code

  7. meson: Fix some grammar usage in Meson comments

  8. meson: Mention the correct way to disable readline support

  9. meson: Remove old comment

  10. meson: Use the not_found_dep constant

  11. meson: Attach colon to keyword argument

  12. meson: Use consistent Meson option description formats

  13. meson: Use consistent casing in Meson option descriptions

  14. meson: Remove triple-quoted strings