public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andres Freund <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: [email protected]
Subject: Re: [RFC] building postgres with meson -v8
Date: Tue, 14 Jun 2022 11:23:07 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

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 <[email protected]>
> 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 <[email protected]>
> 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 <[email protected]>
> 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 <[email protected]>
> 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 <[email protected]>
> 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 <[email protected]>
> Date: Tue, 7 Jun 2022 22:54:26 +0200
> Subject: [PATCH] fixup! meson: prereq: unicode: allow to specify output
>  directory.

Merged.

Greetings,

Andres Freund

view thread (46+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: [RFC] building postgres with meson -v8
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox