Re: meson oddities
От | Andres Freund |
---|---|
Тема | Re: meson oddities |
Дата | |
Msg-id | 20221115234042.zkxyxzv5wgewit33@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: meson oddities (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: meson oddities
|
Список | 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 по дате отправления: