Re: [RFC] building postgres with meson - v13

Hi,

> I'll include an updated pgxs-compat patch in the next post of the series (in a
> few hours).

Attaches is version 17. Other changes:

- Added a new patch to fix the display of user provided CFLAGS in the meson
summary and to add them to pg_config output, addressing the report by Wang Wei
at [1]. Planning to apply this soon. We can fine tune this later, the
current situation is confusing.

- Added a new patch to set rpath to $libdir. I'd hoped we'd quickly go for
relative rpaths (so the install is relocatable, making it trivial to use
tmp_install), but I now think that might take a bit longer. I'm planning to
push this soon, as multiple people have been hit by this.

- Added a patch to separately define static / shared libraries for the ecpg
runtime libraries. This is a prerequisite patch for adding windows resource
files, since the resource files should only be defined for shared libraries.

- The patch adding windows resource files is, I think, now complete, including
adding resource files to the ecpg libs.

- A few more improvements for the PGXS compatibility. The pieces depending on
the changes discussed below are left in a separate patch for now, as I'm not
sure they'll survive as-is... There's a few more things needed, but I think
it's getting closer.

- Made some of the ecpg libraries use precompiled headers as well (gaining
maybe 500ms in a debug build)

One interesting question for this patch is where to add a note about when it
is sensible for a target to use a precompiled header, and when not. At the
moment meson generates a separate precompiled header "object" for each
target (as the flags can differ), so for a full build precompiled headers
can only be a win when a target has > 1 source file.

- Tweaked the patch adding tests against running instances a bit, mainly by
using a different suite name for the 'running' tests (otherwise meson test
--suite something does bad things) and removing the 'tmp-install', 'running'
suites. Haven't yet renamed 'running', as had been suggested by Peter
Geoghegan, his suggestion seemed a bit long.

- Reordered the series so that the patches that might take a while (including
being moved into a separate CF entry & thread) are last. I left the CI
patches at the start, because they make it easier to test parts of the
patchseries (e.g. [2] just checks up to 0004)

On 2022-09-26 12:44:35 -0700, Andres Freund wrote:
> Looking through a few of the not-nicely-replaced things, I think we can
> simplify at least some away:
>
> - RANLIB: most platforms use AROPT = crs, making ranlib unnecessary. {free,
> net, open}bsd don't currently, but all support it from what I know

Done in the attached 0009.

> - with_gnu_ld: this is only used on solaris, to set export_dynamic = -Wl,-E
> when using a gnu ld. How about moving this to configure instead, and just
> checking if -Wl,-E links?

Done in 0011. Together with 0010, which gets rid of the need for $(LD) on aix
by using $(CC) -r instead, this allows us to get rid of libtool.m4

Right now 0011 adds a PGAC_PROG_CC_LD_EXPORT_DYNAMIC() which tests for
-Wl,-E. It's used on solaris only. Based on its return value
SOLARIS_EXPORT_DYNAMIC is set in Makefile.global.

I'm not convinced by the precise structure I came up with in 0011, I'd welcome
feedback. But the idea as a whole seems promising to me.

0008 unifies CFLAGS_SSE42 and CFLAGS_ARMV8_CRC32C. We really don't need two
different variables for this - on the makefile level we really don't need to
care.

I'm wondering about moving the bulk of the pgxs compatibility stuff from
src/meson.build to src/makefiles/meson.build. Will look a bit uglier ('../'
references), but src/meson.build feels a bit too prominent somehow.

Greetings,

Andres Freund

[1] https://postgr.es/m/OS3PR01MB62751847BC9CD2DB7B29AC129E529%40OS3PR01MB6275.jpnprd01.prod.outlook.com
[2] https://cirrus-ci.com/build/6353192312111104