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

From Andres Freund
Subject Re: Remove MSVC scripts from the tree
Date
Msg-id 20231220114027.spqbqbtx5p4enf5y@alap3.anarazel.de
Whole thread Raw
In response to Re: Remove MSVC scripts from the tree  (vignesh C <vignesh21@gmail.com>)
Responses Re: Remove MSVC scripts from the tree
List pgsql-hackers
On 2023-12-20 16:15:55 +0530, vignesh C wrote:
> On Tue, 19 Dec 2023 at 20:54, Peter Eisentraut <peter@eisentraut.org> wrote:
> >
> > On 18.12.23 14:52, Peter Eisentraut wrote:
> > >> 2) I had seen that if sed/gzip is not available meson build will fail:
> > >> 2.a)
> > >> Program gsed sed found: NO
> > >> meson.build:334:6: ERROR: Program 'gsed sed' not found or not executable
> > >
> > > Yes, this would need to be improved.  Currently, sed is only required if
> > > either selinux or dtrace is enabled, which isn't supported on Windows.
> > > But we should adjust the build scripts to not fail the top-level setup
> > > run unless those options are enabled.
> > >
> > >> 2.b)
> > >> Program gzip found: NO
> > >> meson.build:337:7: ERROR: Program 'gzip' not found or not executable
> > >
> > > gzip is only required for certain test suites, so again we should adjust
> > > the build scripts to not fail the build but instead skip the tests as
> > > appropriate.
> >
> > Here are patches for these two issues.  More testing would be appreciated.
> 
> Thanks for the patches, Windows build is successful without these binaries.
> In linux when I try with Dtrace enabled, it throws the following error:
> Compiler for C supports arguments -fPIC: YES
> Compiler for C supports link arguments -Wl,--as-needed: YES
> Configuring pg_config_paths.h using configuration
> 
> src/include/utils/meson.build:39:2: ERROR: Tried to use not-found
> external program in "command"
> 
> With Dtrace enabled we should throw the original error that we were
> getting i.e.:
> ERROR: Program sed not found or not executable

I think the problem is that the current formulation in the patches doesn't
with deal with dtrace=auto. I think we ought to make that in a proper feature
checking block instead of just checking the presence of the dtrace binary.

Hm, or perhaps we should just get rid of sed use altogether. The sepgsql case
is trivially translateable to perl, and postprocess_dtrace.sed isn't
much harder.


OTOH, I actually don't think it's valid to not have sed when you have
dtrace. Erroring out in a weird way in such an artificially constructed test
doesn't really seem like a problem.


> Another observation is that we could include the executable name in
> this case something like:
> ERROR: Tried to use not-found external program "sed" in "command"

It's a meson generated message, so you'd need to open a bug report / feature
request for it.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Synchronizing slots from primary to standby
Next
From: "Drouvot, Bertrand"
Date:
Subject: Re: Function to get invalidation cause of a replication slot.