Re: [RFC] building postgres with meson - autogenerated headers - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [RFC] building postgres with meson - autogenerated headers
Date
Msg-id 1035634.1644269453@sss.pgh.pa.us
Whole thread Raw
In response to Re: [RFC] building postgres with meson - autogenerated headers  (Andres Freund <andres@anarazel.de>)
Responses Re: [RFC] building postgres with meson - autogenerated headers  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> 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.

Agreed, that always seemed entirely random to me too.  I'd be content
to end up with "defined or not defined" as the standard.  I think
we have way more #ifdef tests than #if tests, so changing the latter
seems more sensible than changing the former.

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

TBH I can't get excited about that.  I do not think that rebuilding
with different options is a critical path.  ccache already does most
of the heavy lifting when you do that sort of thing, anyway.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Synchronizing slots from primary to standby
Next
From: Chapman Flack
Date:
Subject: Re: style for typedef of function that will be pointed to