Re: Meson build updates

From: "Tristan Partin" <tristan(at)neon(dot)tech>
To: "Andres Freund" <andres(at)anarazel(dot)de>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Meson build updates
Date: 2023-06-13 19:56:36
Message-ID: CTBSCT2V1TVP.2AUJVJLNWQVG3@gonk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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(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.
> >
> > 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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tristan Partin 2023-06-13 20:12:35 Re: Meson build updates
Previous Message Jeff Davis 2023-06-13 19:54:24 Re: pgsql: Fix search_path to a safe value during maintenance operations.