Re: automating pg_config.h.win32 maintenance

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Fri, Dec 13, 2019 at 03:14:08PM +0200, Heikki Linnakangas wrote:
>> On 13/12/2019 14:51, Peter Eisentraut wrote:
>>> Keeping pg_config.h.win32 up to date with pg_config.h.in is a gratuitous
>>> annoyance.

>> Hear hear!

> Youpi.

+1

>> I don't think this @simple_defines is really any better than listing all the
>> options directly with "$define{HAVE_ATOMICS} = 1". And some simple defines
>> are already listed like that, e.g. HAVE_DECL_STRNLEN above that list.

> Agreed.

Yeah, having one style for setting a variable is better than having two.

One thing that disturbs me slightly is that the plan seems to be to
not mention variables in this list at all if they're to be undefined
on Windows. I realize that we've frequently done that by omission in
pg_config.h.win32, but I don't think it's good practice: it encourages
failure to think about how such variables need to be set on Windows.

Would it be reasonable to require every symbol found in pg_config.h.in
to be explicitly mentioned here? We could put the ones that are to
end up undefined in a separate %undefine hash, or we could have a
convention that an empty value in %define means to #undef it (though
I suppose that might be awkward in a few cases).

Either way, though, we'd end up with a situation where adding a new
configure symbol always requires touching Solution.pm, where before
it required touching pg_config.h.win32 (at least if you were being
strict about it). So in some sense this is no improvement. But we
do have the ability with this to do some computation to select the
variable value, so that's good.

regards, tom lane