Re: [RFC] building postgres with meson - autogenerated headers

Hi,

I've been wondering whether we should try to have the generated pg_config.h
look as similar as possible to autoconf/autoheader's, or not. And whether the
way autoconf/autoheader define symbols makes sense when not using either
anymore.

To be honest, I do not really understand the logic behind when autoconf ends
up with #defines that define a macro to 0/1 and when a macro ends defined/or
not and when we end up with a macro defined to 1 or not defined at all.

So far I've tried to mirror the logic, but not the description / comment
formatting of the individual macros.

The "defined to 1 or not defined at all" behaviour is a mildly awkward to
achieve with meson, because it doesn't match the behaviour for booleans
options meson has (there are two builtin behaviours, one to define/undefine a
macro, the other to set the macro to 0/1. But there's none that defines a
macro to 1 or undefines it).

Probably best to initially have the macros defined as similar as reasonably
possible, but subsequently clean things up a bit.


A second aspect that I'm wondering about is whether we should try to split
pg_config.h output a bit:

With meson it's easy to change options like whether to build with some
dependency in an existing build tree and then still get a reliable build
result (ninja rebuilds if the commandline changed from the last invocation).

But right now doing so often ends up with way bigger rebuilds than necessary,
because for a lot of options we add #define USE_LDAP 1 etc to pg_config.h,
which of course requires rebuilding a lot of files. Even though most of these
symbols are only checked in a handful of files, often only .c files.

It seems like it might make sense to separate out defines that depend on the
compiler / "standard libraries" (e.g. {SIZEOF,ALIGNOF}_*,
HAVE_DECL_{STRNLEN,...}, HAVE_*_H) from feature defines (like
USE_{LDAP,ICU,...}). The header containing the latter could then included in
the places needing it (or we could have one header for each of the places
using it).

Perhaps we should also separate out configure-time settings like BLCKSZ,
DEF_PGPORT, etc. Realistically most of them are going to require a "full tree"
recompile anway, but it seems like it might make things easier to understand.

I think a split into pg_config_{platform,features,settings}.h could make sense.

Similar to above, it's probably best to do this separately after merging meson
support. But knowing what the split should eventually look like would be
helpful before, to ensure it's easy to do.

Greetings,

Andres Freund