Re: meson oddities
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-01-04T11:35:35Z
Lists: pgsql-hackers
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. 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).
Commits
-
meson: Fix installation path computation
- 8f6858064b14 16.0 landed