Thread

Client-only Meson Build From Sources

Benjamin Leff <benjamin.w.leff@gmail.com> — 2025-10-20T20:43:48Z

Hello,

Are there any plans to support a client-only (no server) build in meson?

We currently maintain a libpq-standalone fork
<https://github.com/eugo-inc/libpq-standalone> that we haven’t updated in
about ~1 year and would like to deprecate if possible.

Here’s another
<https://github.com/agostino-code/CSoketLSO/blob/main/lib/libpq-standalone/README.md>
alternative
using CMake.

Thanks,
Ben

--
Benjamin W. Leff
(516) 754-3453
[image: ltp|17609929361245280]

Re: Client-only Meson Build From Sources

Peter Eisentraut <peter@eisentraut.org> — 2025-10-21T07:34:13Z

On 20.10.25 22:43, Benjamin Leff wrote:
> Are there any plans to support a client-only (no server) build in meson?

I'm not aware of such plans.  But that doesn't mean somebody couldn't 
propose one.

Re: Client-only Meson Build From Sources

Tom Lane <tgl@sss.pgh.pa.us> — 2025-10-21T14:57:08Z

Peter Eisentraut <peter@eisentraut.org> writes:
> On 20.10.25 22:43, Benjamin Leff wrote:
>> Are there any plans to support a client-only (no server) build in meson?

> I'm not aware of such plans.  But that doesn't mean somebody couldn't 
> propose one.

Years ago we had support for client-only builds on at least some
toolchains (MSVC at least, not sure about elsewhere).  That got
dropped though.  I believe the prevailing opinion was that the amount
of time saved by not building all of PG didn't justify the maintenance
effort to keep the build scripts working for that case.  I think that
that argument hasn't lost its force, so we'd be likely to reject any
such proposal.

			regards, tom lane

Re: Client-only Meson Build From Sources

Benjamin Leff <benjamin.w.leff@gmail.com> — 2025-10-21T15:23:15Z

> I believe the prevailing opinion was that the amount
of time saved by not building all of PG didn't justify the maintenance
effort to keep the build scripts working for that case

IMO, it’s not just about time. For bare bones package managers when there’s
no need to build the server, this saves a few GB.


--
Benjamin W. Leff
(516) 754-3453


On Tue, Oct 21, 2025 at 9:57 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Peter Eisentraut <peter@eisentraut.org> writes:
> > On 20.10.25 22:43, Benjamin Leff wrote:
> >> Are there any plans to support a client-only (no server) build in meson?
>
> > I'm not aware of such plans.  But that doesn't mean somebody couldn't
> > propose one.
>
> Years ago we had support for client-only builds on at least some
> toolchains (MSVC at least, not sure about elsewhere).  That got
> dropped though.  I believe the prevailing opinion was that the amount
> of time saved by not building all of PG didn't justify the maintenance
> effort to keep the build scripts working for that case.  I think that
> that argument hasn't lost its force, so we'd be likely to reject any
> such proposal.
>
>                         regards, tom lane
>

Re: Client-only Meson Build From Sources

Tom Lane <tgl@sss.pgh.pa.us> — 2025-10-21T16:02:27Z

Benjamin Leff <benjamin.w.leff@gmail.com> writes:
>> I believe the prevailing opinion was that the amount
>> of time saved by not building all of PG didn't justify the maintenance
>> effort to keep the build scripts working for that case

> IMO, it’s not just about time. For bare bones package managers when there’s
> no need to build the server, this saves a few GB.

It's still fundamentally about trading off machine resources versus
people time, though, and that tradeoff is not getting more attractive.

			regards, tom lane

Re: Client-only Meson Build From Sources

Andres Freund <andres@anarazel.de> — 2025-10-22T09:02:01Z

Hi,

On 2025-10-21 12:02:27 -0400, Tom Lane wrote:
> Benjamin Leff <benjamin.w.leff@gmail.com> writes:
> >> I believe the prevailing opinion was that the amount
> >> of time saved by not building all of PG didn't justify the maintenance
> >> effort to keep the build scripts working for that case
> 
> > IMO, it’s not just about time. For bare bones package managers when there’s
> > no need to build the server, this saves a few GB.
> 
> It's still fundamentally about trading off machine resources versus
> people time, though, and that tradeoff is not getting more attractive.

The impact really depends on what we define a client-only build as.

It'd not be hard at all to add a meta target that just builds a subset of the
tree. It'd be slightly harder, but still not that hard, to add a target to
install just a subset of libraries / binaries.

What would be a bit harder would be to add a configure-time switch to only
build client binaries. Mainly because, I think, it'd increase the test matrix
more than a dedicated build target would.

Benjamin, what precisely are you looking for with a client-only build?

Greetings,

Andres Freund

Re: Client-only Meson Build From Sources

Benjamin Leff <benjamin.w.leff@gmail.com> — 2025-12-03T20:16:15Z

Building only a subset of libraries / binaries would be sufficient for our
use case (and even only building a subset of the tree would get us most of
the way there).

A configure-time switch to only build client binaries would be ideal but
perhaps that could be a long term goal.

In our fork we tried to remove anything that wasn't relevant for having a
functioning client.

If this group is open to it, maybe we could figure out how to approach the
low hanging fruit first.

Best,
Benjamin

On Wed, Oct 22, 2025 at 4:02 AM Andres Freund <andres@anarazel.de> wrote:

> Hi,
>
> On 2025-10-21 12:02:27 -0400, Tom Lane wrote:
> > Benjamin Leff <benjamin.w.leff@gmail.com> writes:
> > >> I believe the prevailing opinion was that the amount
> > >> of time saved by not building all of PG didn't justify the maintenance
> > >> effort to keep the build scripts working for that case
> >
> > > IMO, it’s not just about time. For bare bones package managers when
> there’s
> > > no need to build the server, this saves a few GB.
> >
> > It's still fundamentally about trading off machine resources versus
> > people time, though, and that tradeoff is not getting more attractive.
>
> The impact really depends on what we define a client-only build as.
>
> It'd not be hard at all to add a meta target that just builds a subset of
> the
> tree. It'd be slightly harder, but still not that hard, to add a target to
> install just a subset of libraries / binaries.
>
> What would be a bit harder would be to add a configure-time switch to only
> build client binaries. Mainly because, I think, it'd increase the test
> matrix
> more than a dedicated build target would.
>
> Benjamin, what precisely are you looking for with a client-only build?
>
> Greetings,
>
> Andres Freund
>
[image: ltp|17647911066367886]

Re: Client-only Meson Build From Sources

Benjamin Leff <benjamin.w.leff@gmail.com> — 2026-01-02T18:43:34Z

Hey All

Wanted to follow up going into the new year.

For our use case installing a subset of the tree is sufficient.

In order of preference / difficulty:
1) Subset of tree
2) Subset of libs / binaries
3) Configure-time switch to only build client binaries

Is there enough interest to do #1? How can I help?

Happy New Year,
Benjamin

--
Benjamin W. Leff


On Wed, Dec 3, 2025 at 2:16 PM Benjamin Leff <benjamin.w.leff@gmail.com>
wrote:

> Building only a subset of libraries / binaries would be sufficient for our
> use case (and even only building a subset of the tree would get us most of
> the way there).
>
> A configure-time switch to only build client binaries would be ideal but
> perhaps that could be a long term goal.
>
> In our fork we tried to remove anything that wasn't relevant for having a
> functioning client.
>
> If this group is open to it, maybe we could figure out how to approach the
> low hanging fruit first.
>
> Best,
> Benjamin
>
>
>
> On Wed, Oct 22, 2025 at 4:02 AM Andres Freund <andres@anarazel.de> wrote:
>
>> Hi,
>>
>> On 2025-10-21 12:02:27 -0400, Tom Lane wrote:
>> > Benjamin Leff <benjamin.w.leff@gmail.com> writes:
>> > >> I believe the prevailing opinion was that the amount
>> > >> of time saved by not building all of PG didn't justify the
>> maintenance
>> > >> effort to keep the build scripts working for that case
>> >
>> > > IMO, it’s not just about time. For bare bones package managers when
>> there’s
>> > > no need to build the server, this saves a few GB.
>> >
>> > It's still fundamentally about trading off machine resources versus
>> > people time, though, and that tradeoff is not getting more attractive.
>>
>> The impact really depends on what we define a client-only build as.
>>
>> It'd not be hard at all to add a meta target that just builds a subset of
>> the
>> tree. It'd be slightly harder, but still not that hard, to add a target to
>> install just a subset of libraries / binaries.
>>
>> What would be a bit harder would be to add a configure-time switch to only
>> build client binaries. Mainly because, I think, it'd increase the test
>> matrix
>> more than a dedicated build target would.
>>
>> Benjamin, what precisely are you looking for with a client-only build?
>>
>> Greetings,
>>
>> Andres Freund
>>
> [image: ltp|17647911066367886]
>
[image: ltp|17673783065384987]

Re: Client-only Meson Build From Sources

Andres Freund <andres@anarazel.de> — 2026-01-02T18:48:33Z

Hi,

On 2026-01-02 12:43:34 -0600, Benjamin Leff wrote:
> For our use case installing a subset of the tree is sufficient.
> 
> In order of preference / difficulty:
> 1) Subset of tree

What precisely do you mean by this?

> 2) Subset of libs / binaries

Why is 1) peferrable over 2)?

> 3) Configure-time switch to only build client binaries

I really doubt there's interest in going there.

FYI, on the postgres list we try to quote properly, quoting the old message at
the bottom of your email, without any trimming, is likely to lead to fewer
responses.

Greetings,

Andres Freund

Re: Client-only Meson Build From Sources

Benjamin Leff <benjamin.w.leff@gmail.com> — 2026-01-02T19:46:51Z

Hi Andres,

Apologies for the poor communication.

On 2026-01-02 12:48:34, Andres Freund wrote:
> On 2026-01-02 12:43:34 -0600, Benjamin Leff wrote:
> > For our use case installing a subset of the tree is sufficient.
> >
> > In order of preference / difficulty:
> > 1) Subset of tree
>
> What precisely do you mean by this?

Poor communication on my part. When I said "in order of preference /
difficulty" I meant in order of difficulty/ease of implementation for
maintainers (that also satisfies our needs), not our actual preference.

Said differently, let's start with the easiest / lowest hanging fruit first
to minimize maintenance burden. A meta target that builds only client
portions of the tree seems like the lightest-weight approach.

> > 2) Subset of libs / binaries
>
> Why is 1) peferrable over 2)?

It's not (again I communicated poorly). #2 (install target filtering
specific libs/binaries) would actually be better for our use case since it
saves both build time and disk space. But since you mentioned #2 would be
"slightly harder" in your earlier email, I was trying to suggest we tackle
#1 first if that's easier to implement and maintain.

> > 3) Configure-time switch to only build client binaries
>
> I really doubt there's interest in going there.

Understood.

I'm happy to help however I can and support the approach that makes the
most sense from a maintenance perspective.

Let me know if that helps clarify!

Thanks,
Benjamin

--
Benjamin W. Leff

Re: Client-only Meson Build From Sources

Jaroslaw Ciba <jaroslaw.ciba@carallon.com> — 2026-01-15T18:29:43Z

Hey all,

Just thought I would bump this thread given Benjamin has been the only one to request the feature thus far. It was nice to bump into this thread when I was evaluating client-side builds in December myself.

We'd be interested in a stripped down libpq as well; a couple of our embedded Linux platforms built in Buildroot include PostgreSQL, and it accounts for roughly 15% and 20% of our firmware bundles respectively - one of the taller nails in the BSPs. Both of these platforms are only ever clients!

With autoconf it is trivial to get a client-side version only - just 4 make commands do the trick. As part of upgrading BSPs I considered adding an internal Buildroot package relying on this, given it's a good opportunity to go through smoke testing and see it not break anything, but I currently do not want to increase the maintenance burden in moving BSPs forward. I'm also not particularly keen on adding a dependency on autoconf/make given it's only been said it won't be dropped in the near future - I don't particularly want some developer here in 5 years' time to have to tear their hair out! Having this problem solved externally would be great, though I more than understand the need to balance resources.

Best,
Jaroslaw Ciba

________________________________
From: Benjamin Leff <benjamin.w.leff@gmail.com>
Sent: 03 December 2025 20:16
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter@eisentraut.org>; pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Subject: Re: Client-only Meson Build From Sources

You don't often get email from benjamin.w.leff@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Building only a subset of libraries / binaries would be sufficient for our use case (and even only building a subset of the tree would get us most of the way there).

A configure-time switch to only build client binaries would be ideal but perhaps that could be a long term goal.

In our fork we tried to remove anything that wasn't relevant for having a functioning client.

If this group is open to it, maybe we could figure out how to approach the low hanging fruit first.

Best,
Benjamin

On Wed, Oct 22, 2025 at 4:02 AM Andres Freund <andres@anarazel.de<mailto:andres@anarazel.de>> wrote:
Hi,

On 2025-10-21 12:02:27 -0400, Tom Lane wrote:
> Benjamin Leff <benjamin.w.leff@gmail.com<mailto:benjamin.w.leff@gmail.com>> writes:
> >> I believe the prevailing opinion was that the amount
> >> of time saved by not building all of PG didn't justify the maintenance
> >> effort to keep the build scripts working for that case
>
> > IMO, it’s not just about time. For bare bones package managers when there’s
> > no need to build the server, this saves a few GB.
>
> It's still fundamentally about trading off machine resources versus
> people time, though, and that tradeoff is not getting more attractive.

The impact really depends on what we define a client-only build as.

It'd not be hard at all to add a meta target that just builds a subset of the
tree. It'd be slightly harder, but still not that hard, to add a target to
install just a subset of libraries / binaries.

What would be a bit harder would be to add a configure-time switch to only
build client binaries. Mainly because, I think, it'd increase the test matrix
more than a dedicated build target would.

Benjamin, what precisely are you looking for with a client-only build?

Greetings,

Andres Freund
[ltp|17647911066367886]

Re: Client-only Meson Build From Sources

Benjamin Leff <benjamin.w.leff@gmail.com> — 2026-01-15T18:53:51Z

> We'd be interested in a stripped down libpq as well; a couple of our
embedded Linux platforms built in Buildroot include PostgreSQL, and it
accounts for roughly 15% and 20% of our firmware bundles respectively - one
of the taller nails in the BSPs. Both of these platforms are only ever
clients!

If this feature doesn't move forward in postgres, if you're interested,
would love the help syncing our stripped down fork with upstream.

>  I'm also not particularly keen on adding a dependency on autoconf/make

This is true for us too. We're trying to reduce all reliance on autoconf.

--
Benjamin W. Leff


On Thu, Jan 15, 2026 at 12:29 PM Jaroslaw Ciba <jaroslaw.ciba@carallon.com>
wrote:

> Hey all,
>
> Just thought I would bump this thread given Benjamin has been the only one
> to request the feature thus far. It was nice to bump into this thread when
> I was evaluating client-side builds in December myself.
>
> We'd be interested in a stripped down libpq as well; a couple of our
> embedded Linux platforms built in Buildroot include PostgreSQL, and it
> accounts for roughly 15% and 20% of our firmware bundles respectively - one
> of the taller nails in the BSPs. Both of these platforms are only ever
> clients!
>
> With autoconf it is trivial to get a client-side version only - just 4
> make commands do the trick. As part of upgrading BSPs I considered adding
> an internal Buildroot package relying on this, given it's a good
> opportunity to go through smoke testing and see it not break anything, but
> I currently do not want to increase the maintenance burden in moving BSPs
> forward. I'm also not particularly keen on adding a dependency on
> autoconf/make given it's only been said it won't be dropped in the near
> future - I don't particularly want some developer here in 5 years' time to
> have to tear their hair out! Having this problem solved externally would be
> great, though I more than understand the need to balance resources.
>
> Best,
> Jaroslaw Ciba
>
[image: ltp|17685019294754567]

Re: Client-only Meson Build From Sources

Andres Freund <andres@anarazel.de> — 2026-01-15T18:58:18Z

Hi,

On 2026-01-15 18:29:43 +0000, Jaroslaw Ciba wrote:
> We'd be interested in a stripped down libpq as well; a couple of our
> embedded Linux platforms built in Buildroot include PostgreSQL, and it
> accounts for roughly 15% and 20% of our firmware bundles respectively - one
> of the taller nails in the BSPs. Both of these platforms are only ever
> clients!

What specifically do you mean with a stripped down libpq?  Just without
optional dependencies, which certainly do increase the installed size, or
something more?

> With autoconf it is trivial to get a client-side version only - just 4 make
> commands do the trick.

It'd be a few lines to add a 'libpq' and 'install-libpq' targets, I assume
that'd do the trick for you?  I assume you also need the headers being
installed?

Greetings,

Andres Freund