Re: meson oddities - Mailing list pgsql-hackers
From | Andres Freund |
---|---|
Subject | Re: meson oddities |
Date | |
Msg-id | 20230104193502.ax5gmgt6yqznolvm@awork3.anarazel.de Whole thread Raw |
In response to | Re: meson oddities (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Responses |
Re: meson oddities
Re: meson oddities |
List | pgsql-hackers |
Hi, On 2023-01-04 12:35:35 +0100, Peter Eisentraut wrote: > On 16.11.22 18:07, Andres Freund wrote: > > > > If I just want to install postgres into a prefix without 'postgresql' added in > > > > a bunch of directories, e.g. because I already have pg-$version to be in the > > > > prefix, there's really no good way to do so - you can't even specify > > > > --sysconfdir or such, because we just override that path. > > > > > > At least for the libraries, the point of the 'postgresql' subdir IMO > > > is to keep backend-loadable extensions separate from random libraries. > > > It's not great that we may fail to do that depending on what the > > > initial part of the library path is. > > > > Agreed, extensions really should never be in a path searched by the dynamic > > linker, even if the prefix contains 'postgres'. > > > > To me that's a separate thing from adding postgresql to datadir, sysconfdir, > > includedir, docdir... On a green field I'd say the 'extension library' > > directory should just always be extensions/ or such. > > I think we should get the two build systems to produce the same installation > layout when given equivalent options. I'm not convinced that that's the right thing to do. Distributions have helper infrastructure for buildsystems - why should we make it harder for them by deviating further from the buildsystem defaults? I have yet to hear an argument why installing libraries below /usr/[local]/lib/{x86_64,i386,...}-linux-{gnu,musl,...}/ is the wrong thing to do on Debian based systems (or similar, choosing lib64 over lib on RH based systems). But at the same time I haven't heard of an argument why we should break existing scripts building with autoconf for this. To me a different buildsystem is a convenient point to adapt to build path from the last decade. > Unless someone comes up with a proposal to address the above broader issues, > also taking into account current packaging practices etc., then I think we > should do a short-term solution to either port the subdir-appending to the > meson scripts or remove it from the makefiles (or maybe a bit of both). Just to be clear, with 'subdir-appending' you mean libdir defaulting to 'lib/x86_64-linux-gnu' (or similar)? Or do you mean adding 'postgresql' into various dirs when the path doesn't already contain postgres? I did try to mirror the 'postgresql' adding bit in the meson build. Greetings, Andres Freund
pgsql-hackers by date: