From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [RFC] building postgres with meson -v8 |
Date: | 2022-06-14 18:23:07 |
Message-ID: | 20220614182307.c4rmo25y3khhkc6u@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-06-08 08:27:06 +0200, Peter Eisentraut wrote:
> 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.
Yea, I should probably post that to the relevant thread. I think at that point
I was just trying to get a rebase not to fail anymore...
> 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.
I got failures on windows without it - which we just don't see on windows
because currently nothing runs these tests :(. The pg_verifybackup case likely
is unproblematic because it uses the array form of building subcommands,
instead of string interpolation.
> 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).
Merged.
> 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.)
Not sure why I didn't do that. It might be because the meson capture stuff has
a noticable overhead, particularly on windows, because it starts up a python
interpreter. Since nearly the whole build depends on generate-errcodes.pl to
have run...
> 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.
I don't really have an opinion what's better here, so I'll go with your
preference / the option.
> 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.
Getopt::Long auto-generates short options afaict...
> 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).
Will take a stab at doing so.
> From 51c6d3544ae9e652c7aac26102a8bf5a116fb182 Mon Sep 17 00:00:00 2001
> From: Peter Eisentraut <peter(at)eisentraut(dot)org>
> Date: Tue, 7 Jun 2022 22:54:26 +0200
> Subject: [PATCH] fixup! meson: prereq: unicode: allow to specify output
> directory.
Merged.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-06-14 18:27:28 | Re: [RFC] building postgres with meson -v8 |
Previous Message | Peter Geoghegan | 2022-06-14 18:23:01 | Re: better page-level checksums |