meson PGXS compatibility - Mailing list pgsql-hackers
From | Andres Freund |
---|---|
Subject | meson PGXS compatibility |
Date | |
Msg-id | 20221005200710.luvw5evhwf6clig6@awork3.anarazel.de Whole thread Raw |
Responses |
Re: meson PGXS compatibility
Re: meson PGXS compatibility Re: meson PGXS compatibility Re: meson PGXS compatibility Re: meson PGXS compatibility |
List | pgsql-hackers |
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
Attachment
pgsql-hackers by date: