Thread: meson PGXS compatibility

meson PGXS compatibility

From

Andres Freund

Date:

05 October 2022, 23:07:10

Hi,

As the meson support stands right now, one cannot easily build an extension
against a postgres built with meson. As discussed at the 2022 unconference
[1], one way to make that easier for extensions is for meson to generate a
complete enough Makefile.global for pgxs.mk to work.

This is a series of patches towards that goal. The first four simplify some
aspects of Makefile.global, and then the fifth generates Makefile.global etc.

0001: autoconf: Unify CFLAGS_SSE42 and CFLAGS_ARMV8_CRC32C

Right now emit the cflags to build the CRC objects into architecture specific
variables. That doesn't make a whole lot of sense to me - we're never going to
target x86 and arm at the same time, so they don't need to be separate
variables.

It might be better to instead continue to have CFLAGS_SSE42 /
CFLAGS_ARMV8_CRC32C be computed by PGAC_ARMV8_CRC32C_INTRINSICS /
PGAC_SSE42_CRC32_INTRINSICS and then set CFLAGS_CRC based on those. But it
seems unlikely that we'd need other sets of flags for those two architectures
at the same time.

The separate flags could be supported by the meson build instead, it'd just
add unneccessary complexity.

0002: autoconf: Rely on ar supporting index creation

With meson we don't require ranlib. But as it is set in Makefile.global and
used by several platforms, we'd need to detect it.

FreeBSD, NetBSD, OpenBSD, the only platforms were we didn't use AROPT=crs,
all have supported the 's' option for a long time.

On macOS we ran ranlib after installing a static library. This was added a
long time ago, in 58ad65ec2def. I cannot reproduce an issue in more recent
macOS versions.

I'm on the fence about removing the "touch $@" from the rule building static
libs. That was added because of macos's ranlib not setting fine-grained
timestamps. On a modern mac ar and ranlib are the same binary, and maybe
that means that ar has the same issue? Both do set fine-grained
timestamps:

cc ../test.c -o test.o -c
rm -f test.a; ar csr test.a test.o ; ranlib test.a; python3 -c "import os;print(os.stat('test.a').st_mtime_ns)"
1664999109090448534

But I don't know how far back that goes. We could just reformulate the
comment to mention ar instead of ranlib.

Tom, CCing you due to 58ad65ec2def and 826eff57c4c.

0003: aix: Build SUBSYS.o using $(CC) -r instead of $(LD) -r

This is the only direct use of $(LD), and xlc -r and gcc -r end up with the
same set of symbols and similar performance (noise is high, so hard to say if
equivalent).

Now that $(LD) isn't needed anymore, remove it from src/Makefile.global

While at it, add a comment why -r is used.

0004: solaris: Check for -Wl,-E directly instead of checking for gnu LD

This allows us to get rid of the nontrivial detection of with_gnu_ld,
simplifying meson PGXS compatibility. It's also nice to delete libtool.m4.

I don't like the SOLARIS_EXPORT_DYNAMIC variable I invented. If somebody has
a better idea...

0005: meson: Add PGXS compatibility

The actual meson PGXS compatibility. Plenty more replacements to do, but
suffices to build common extensions on a few platforms.

What level of completeness do we want to require here?

A few replacements worth thinking about:

- autodepend - I'm inclined to set it to true when using a gcc like
compiler. I think extension authors won't be happy if suddenly their
extensions don't rebuild reliably anymore. An --enable-depend like
setting doesn't make sense for meson, so we don't have anything to source it
from.
- {LDAP,UUID,ICU}_{LIBS,CFLAGS} - might some extension need them?

For some others I think it's ok to not have replacement. Would be good for
somebody to check my thinking though:

- LIBOBJS, PG_CRC32C_OBJS, TAS: Not needed because we don't build
the server / PLs with the generated makefile
- ZIC: only needed to build tzdata as part of server build
- MSGFMT et al: translation doesn't appear to be supported by pgxs, correct?
- XMLLINT et al: docs don't seem to be supported by pgxs
- GENHTML et al: supporting coverage for pgxs-in-meson build doesn't seem worth it
- WINDRES: I don't think extensions are bothering to generate rc files on windows

My colleague Bilal has set up testing and verified that a few extensions build
with the pgxs compatibility layer, on linux at last. Currently pg_qualstats,
pg_cron, hypopg, orafce, postgis, pg_partman work. He also tested pgbouncer,
but for him that failed both with autoconf and meson generated pgxs.

I wonder if and where we could have something like this tested continually?

Greetings,

Andres Freund

[1] https://wiki.postgresql.org/wiki/PgCon_2022_Developer_Unconference#Meson_new_build_system_proposal

Thread: meson PGXS compatibility

Attachment

Attachment

Attachment