Обсуждение: Client-only Meson Build From Sources

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.

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

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

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

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

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