Hi,
On 2022-12-19 10:20:45 -0500, Tom Lane wrote:
> Their comment density is pretty awful too --- maybe I'm just
> not used to meson, but they seem just about completely undocumented.
> And there's certainly been no effort to transfer the accumulated wisdom
> of the makefile comments (where it's still relevant, of course).
I did try to retain comments that seemed useful. E.g.
toplevel meson.build:
# The separate ldap_r library only exists in OpenLDAP < 2.5, and if we
# have 2.5 or later, we shouldn't even probe for ldap_r (we might find a
# library from a separate OpenLDAP installation). The most reliable
# way to check that is to check for a function introduced in 2.5.
...
# We are after Embed's ldopts, but without the subset mentioned in
# Config's ccdlflags and ldflags. (Those are the choices of those who
# built the Perl installation, which are not necessarily appropriate
# for building PostgreSQL.)
...
# Functions introduced in OpenSSL 1.1.0. We used to check for
# OPENSSL_VERSION_NUMBER, but that didn't work with 1.1.0, because LibreSSL
# defines OPENSSL_VERSION_NUMBER to claim version 2.0.0, even though it
# doesn't have these OpenSSL 1.1.0 functions. So check for individual
# functions.
...
# Check if the C compiler understands __builtin_$op_overflow(),
# and define HAVE__BUILTIN_OP_OVERFLOW if so.
#
# Check for the most complicated case, 64 bit multiplication, as a
# proxy for all of the operations. To detect the case where the compiler
# knows the function but library support is missing, we must link not just
# compile, and store the results in global variables so the compiler doesn't
# optimize away the call.
...
src/backend/meson.build:
...
# As of 1/2010:
# The probes.o file is necessary for dtrace support on Solaris, and on recent
# versions of systemtap. (Older systemtap releases just produce an empty
# file, but that's okay.) However, macOS's dtrace doesn't use it and doesn't
# even recognize the -G option. So, build probes.o except on macOS.
# This might need adjustment as other platforms add dtrace support.
I'm sure there are a lot of comments that could also have been useful
that I missed - but there's also a lot that just didn't seem
meaningful. E.g. stuff like
# The following targets are specified in make commands that appear in
# the make files in our subdirectories. Note that it's important we
# match the dependencies shown in the subdirectory makefiles!
# Also, in cases where a subdirectory makefile generates two files in
# what's really one step, such as bison producing both gram.h and gram.c,
# we must request making the one that is shown as the secondary (dependent)
# output, else the timestamp on it might be wrong. By project convention,
# the .h file is the dependent one for bison output, so we need only request
# that; but in other cases, request both for safety.
which just doesn't apply to meson.
- Andres
