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;