Re: meson files copyright

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: meson files copyright
Дата
Msg-id 20221220173558.r6qyfezplqvm26rs@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: meson files copyright  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: meson and tmp_install
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Inconsistency in reporting checkpointer stats