Re: [RFC] building postgres with meson - v11

On 11.08.22 02:20, Andres Freund wrote:
> Attached is a new version of the meson patchset. Plenty changes:

I have various bits of comments on this.

- There are various references to "pch" (pre-compiled headers).  Is
   there more discussion anywhere about this?  I don't know what this
   would entail or whether there are any drawbacks to be aware of.  The
   new *_pch.h files don't have any comments.  Maybe this should be a
   separate patch later.

- About relativize_shared_library_references: We have had several
   patches over the years for working around SIP stuff, and some of
   them did essentially this, but we decided not to go ahead with them.
   We could revisit that, but it should be a separate patch, not mixed
   in with this.

- postgresql-extension.pc: Similarly, this ought to be a separate
   patch.  If we want people to use this, we'll need it in the makefile
   build system anyway.

- -DFRONTEND is used somewhat differently from the makefiles.  For
    example, meson sets -DFRONTEND for pg_controldata, but the
    makefiles don't.  Conversely, the makefiles set -DFRONTEND for
    ecpglib, but meson does not.  This should be checked again to make
    sure it all matches up.

- Option name spelling should be make consistent about underscores
   versus hyphens.  Built-in meson options use underscores, so we
   should make the user-defined ones like that as well (some already
   do).  (wal-blocksize krb-srvnam system-tzdata tap-tests bsd-auth)

- I have found the variable name "cdata" for configuration_data() to
   be less than clear.  I see some GNOME projects to it that way, is
   that where it's from?  systemd uses "conf", maybe that's better.

- In the top-level meson.build, the "renaming" of the Windows system
   name

       host_system = host_machine.system() == 'windows' ? 'win32' : 
host_machine.system()
       build_system = build_machine.system() == 'windows' ? 'win32' : 
build_machine.system()

   seems unnecessary to me.  Why not stick with the provided names?

- The c99_test ought to be not needed if the c_std project option is
   used.  Was there a problem with that?

- Is there a way to split up the top-level meson.build somehow?  Maybe
   just throw some stuff into included files?  This might get out of
   hand at some point.

- The PG_SYSROOT detection gives different results.  On my system,
   configure produces
 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk,
   meson produces
 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk.
   src/template/darwin goes out of its way to get a version-specific
   result, so we need to carry that over somehow.  (The difference does
   result in differences in the built binaries.)


Then, some patches from me:

0001-Change-shared-library-installation-naming-on-macOS.patch

This changes the makefiles to make the shared library file naming on
macOS match what meson produces.  I don't know what the situation is
on other platforms.

0002-meson-Fix-installation-name-of-libpgfeutils.patch

This was presumably an accidental mistake.

0003-meson-Libraries-need-to-be-built-with-DSO_MAJOR_VERS.patch

This is needed to make NLS work for the libraries.

0004-meson-Add-darwin_versions-argument-for-libraries.patch

This is to make the output match what Makefile.shlib produces.

0005-meson-Fix-link-order-of-support-libraries.patch
0006-meson-Make-link-order-of-external-libraries-match-ma.patch
0007-WIP-meson-Make-link-order-of-object-files-match-make.patch

I have analyzed the produced binaries between both build systems to
make sure they match.  If we link the files and libraries in different
orders, that becomes difficult.  So this fixes this up a bit.  0005 is
needed for correctness in general, I think.  0006 is mostly cosmetic.
You probably wanted to make the library order alphabetical in the
meson files, which I'd support, but then we should change the
makefiles to match.  Similarly, 0007, which is clearly a bit messy at
the moment, but we should try to sort that out either in the old or
the new build files.


And finally some comments on your patches:

meson: prereq: Don't add HAVE_LDAP_H HAVE_WINLDAP_H to pg_config.h.

This can go ahead.

meson: prereq: fix warning compat_informix/rnull.pgc with msvc

-   $float f = 3.71;
+   $float f = (float) 3.71;

This could use float literals like

+   $float f = 3.71f;