Re: Meson build updates

Поиск
Список
Период
Сортировка
От Tristan Partin
Тема Re: Meson build updates
Дата
Msg-id CTBSCT2V1TVP.2AUJVJLNWQVG3@gonk
обсуждение исходный текст
Ответ на Re: Meson build updates  (Andres Freund <andres@anarazel.de>)
Ответы Re: Meson build updates  (Andres Freund <andres@anarazel.de>)
Список 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)



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: Document that server will start even if it's unable to open some TCP/IP ports
Следующее
От: "Tristan Partin"
Дата:
Сообщение: Re: Meson build updates