Re: [RFC] building postgres with meson -v8

I looked at some of the "prereq" patches again to see what state they
are in:

commit 351a12f48e395b31cce4aca239b934174b36ea9d
Author: Andres Freund <andres(at)anarazel(dot)de>
Date: Wed Apr 20 22:46:54 2022

prereq: deal with \ paths in basebackup_to_shell tests.

This is a new component in PG15, so a fix might be in scope for PG15
too. But I don't know if this change is really necessary. There are
other tests that use the GZIP and TAR environment variables (e.g.,
pg_verifybackup). If this is a problem there too, we should think of a
general solution. If not, it could use some explanation.

commit c00642483a53f4ee6e351085c7628363c293ee61
Author: Andres Freund <andres(at)anarazel(dot)de>
Date: Fri Mar 25 21:44:48 2022

meson: prereq: unicode: allow to specify output directory.

OK with attached fixup (but see below).

commit 31313056e153e099f236a29b752f7610c4f7764f
Author: Andres Freund <andres(at)anarazel(dot)de>
Date: Thu Jan 20 08:36:50 2022

meson: prereq: generate-errcodes.pl: accept output file

This is ok, but seems unnecessary, since meson can capture the output of
a single file. (See also similar script generate-errcodes-table.pl in
doc/, which uses capture.)

commit e4e77c0e20f3532be4ed270a7cf8b965b7cafa49
Author: Andres Freund <andres(at)anarazel(dot)de>
Date: Thu Jan 20 08:36:50 2022

meson: prereq: add output path arg in generate-lwlocknames.pl

We should make the command-line interface here the same as the unicode
script: Either make the output directory a positional argument or an
option. I don't have a strong feeling about it either way, but perhaps
the solution with the option is more elegant and would also not require
changing the makefiles. Also, we should decide on short or long option:
The code declares a long option, but the build uses a short option.
It's confusing that that even works.

commit 7866620afa65223f6e657da972f501615fd32d3b
Author: Andres Freund <andres(at)anarazel(dot)de>
Date: Wed Apr 20 21:01:31 2022

meson: prereq: output and depencency tracking work.

This could be split into multiple parts with more detailed explanations.
I see where you're going but not everything is fully clear to me
(especially the guc-file.c.h stuff).