meson PGXS compatibility

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