Re: meson oddities - Mailing list pgsql-hackers

From Andres Freund
Subject Re: meson oddities
Date
Msg-id 20221115234042.zkxyxzv5wgewit33@awork3.anarazel.de
Whole thread Raw
In response to Re: meson oddities  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: meson oddities
List pgsql-hackers
Hi,

On 2022-11-15 16:08:35 -0500, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > On 2022-11-15 Tu 14:04, Andres Freund wrote:
> >> I don't think it's a virtue to break the layout of the platform by
> >> e.g. installing 64bit libs into the directory containing 32bit libs.
>
> > You might end up surprising people who have installed from source for
> > years and will have the layout suddenly changed, especially on RedHat
> > flavored systems.

Just to make sure that's clear: meson defaults to lib/ or lib64/ (depending on
bitness obviously) on RedHat systems, not lib/i386-linux-gnu/ or
lib/x86_64-linux-gnu.


> Yeah, I'm not too pleased with this idea either.  The people who want
> to install according to some platform-specific plan have already figured
> out how to do that.  People who are accustomed to the way PG has done
> it in the past are not likely to think this is an improvement.

I think that's a good argument to not change the default for configure, but
imo not a good argument for forcing 'lib' rather than the appropriate platform
default in the meson build, given that that already requires changing existing
recipes.

Small note: I didn't intentionally make that change during the meson porting
work, it's just meson's default.

I can live with forcing lib/, but I don't think it's the better solution long
term. And this seems like the best point for switching we're going to get.


We'd just have to add 'libdir=lib' to the default_options array in the
toplevel meson.build.


> Also, unless you intend to drop the special cases involving whether
> the install path string contains "postgres" or "pgsql", it's already
> not platform-standard.

For me that's the best argument for forcing 'lib'. Still not quite enough to
swing me around, because it's imo a pretty reasonable thing to want to install
a 32bit and 64bit libpq, and I don't think we should make that harder.

Somewhat relatedly, I wonder if we should have a better way to enable/disable
the 'pgsql' path logic. It's pretty annoying that prefix basically doesn't
work if it doesn't contain 'pgsql' or 'postgres'.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Sergey Shinderuk
Date:
Subject: Bug in row_number() optimization
Next
From: Michael Paquier
Date:
Subject: Re: Meson add host_system to PG_VERSION_STR