Re: Remove MSVC scripts from the tree

From: Andres Freund <andres(at)anarazel(dot)de>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Shubham Khanna <khannashubham1197(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Remove MSVC scripts from the tree
Date: 2023-12-20 11:40:27
Message-ID: 20231220114027.spqbqbtx5p4enf5y@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2023-12-20 16:15:55 +0530, vignesh C wrote:
> On Tue, 19 Dec 2023 at 20:54, Peter Eisentraut <peter(at)eisentraut(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Drouvot, Bertrand 2023-12-20 11:43:45 Re: Function to get invalidation cause of a replication slot.
Previous Message Amit Kapila 2023-12-20 11:36:51 Re: Synchronizing slots from primary to standby