Re: Remove MSVC scripts from the tree - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Remove MSVC scripts from the tree
Date
Msg-id 3fd0f1bc-4483-4ba9-8aa0-64765b052039@eisentraut.org
Whole thread Raw
In response to Re: Remove MSVC scripts from the tree  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Remove MSVC scripts from the tree
Re: Remove MSVC scripts from the tree
List pgsql-hackers
On 12.10.23 07:23, Michael Paquier wrote:
>> - Is src/backend/utils/README.Gen_dummy_probes still correct after this?
>> AFAICT, the Perl-based MSVC build system uses Gen_dummy_probes.pl, but the
>> meson build uses Gen_dummy_probes.sed even on Windows.  Is that correct,
>> intended?
> Interesting point.  This may depend on the environment at the end?  As
> far as I can see, sed is currently a hard requirement in the meson
> build and we'd fail if the command cannot be used.  The buildfarm
> machines that test meson are able to find sed, making
> Gen_dummy_probes.pl not necessary:
> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=drongo&dt=2023-10-11%2020%3A21%3A17&stg=configure
> 
> So the $1000 question is: could there be a point in keeping the perl
> script around if sed cannot be found?  The buildfarm coverage is
> currently saying no thanks to chocolatey, at least.  The VM images
> compiled by Andres for the CI seem to have the same opinion.

I don't think we should rely on sed being there on Windows.  Maybe it's 
true now on the handful of buildfarm/CI machines and early adopters, but 
do we have any indication that that is systematic or just an accident?

Since we definitely require Perl now, we could just as well use the Perl 
script and avoid this issue.

Attached is a Perl version of the sed script, converted by hand (so not 
the super-verbose s2p thing).  It's basically just the sed script with 
semicolons added and the backslashes in the regular expressions moved 
around.  I think we could use something like that for all platforms now.


Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [PoC] pg_upgrade: allow to upgrade publisher node
Next
From: Bharath Rupireddy
Date:
Subject: Re: Add new option 'all' to pg_stat_reset_shared()