Re: [RFC] building postgres with meson -v8

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-04-21 20:56:37
Message-ID: 20220421205637.liquojkuopd6ffl4@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-04-21 22:36:01 +0200, Peter Eisentraut wrote:
> On 20.04.22 23:04, Andres Freund wrote:
> > > 0003-Fix-warnings-about-deprecated-features.patch
> > >
> > > This fixes some deprecation warnings and raises the requirement to 0.56.
> >
> > I don't see any deprecation warnings - I see some notices about *future*
> > deprecated features being used:
> >
> > NOTICE: Future-deprecated features used:
> > * 0.55.0: {'ExternalProgram.path'}
> > * 0.56.0: {'meson.source_root', 'meson.build_root'}
> >
> > (i.e. once the minimum version is increased to > 0.54, those will trigger
> > deprecation warnings)
> >
> > What are you seeing with what version?
>
> I see the same thing. Effectively, "deprecation warning" and
> "future-deprecation notice" are just different spellings of "yelling at me
> unconditionally for using code that I can't do anything about".

Yea, I'm not happy that "future-deprecation notice" was enabled by
default. It's still different from "deprecation warning" in prominence and
behaviour (e.g. --fatal-meson-warnings doesn't error out for notices but not
for errors), but ...

Might be worth raising with the meson folks.

> > > I'm not sure why the current cutoff at 0.54 was chosen. Perhaps that could
> > > be documented.
> >
> > Not quite sure why I ended up with 0.54. We definitely should require at most
> > 0.56, as that's the last version supporting python 3.5.
>
> Why is Python 3.5 relevant?

It's the latest available on some older platforms. It's pretty easy to install
a new meson, a heck of a lot more work to install a new python. IIRC solaris,
AIX and some of Tom's dinosaurs.

> > > From 1f80e1ebb8efeb0eba7d57032282520fd6455b0d Mon Sep 17 00:00:00 2001
> > > From: Peter Eisentraut <peter(at)eisentraut(dot)org>
> > > Date: Wed, 13 Apr 2022 11:50:52 +0200
> > > Subject: [PATCH 5/5] Workaround for Perl detection
> > >
> > > ---
> > > meson.build | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/meson.build b/meson.build
> > > index 1bf53ea24d..e33ed11b08 100644
> > > --- a/meson.build
> > > +++ b/meson.build
> > > @@ -545,9 +545,9 @@ else
> > > # file existence.
> > > if perl_may_work
> > > perl_ccflags += ['-I(at)0@'.format(perl_inc_dir)]
> > > - if host_machine.system() == 'darwin'
> > > - perl_ccflags += ['-iwithsysroot', perl_inc_dir]
> > > - endif
> > > + #if host_machine.system() == 'darwin'
> > > + # perl_ccflags += ['-iwithsysroot', perl_inc_dir]
> > > + #endif
> > > endif
> >
> > What problem do you see without this? It did build on CI and on my m1 mini box
> > as is...
>
> I'm using homebrew-installed gcc and homebrew-installed perl. gcc doesn't
> understand the option -iwithsysroot, and apparently whatever it points to is
> not needed.

Ah, I only tested with system "cc".

> Note that in configure.ac the logic is like this:
>
> if test \! -f "$perl_archlibexp/CORE/perl.h" ; then
> if test -f "$PG_SYSROOT$perl_archlibexp/CORE/perl.h" ; then
> perl_includespec="-iwithsysroot $perl_archlibexp/CORE"
> fi
> fi
>
> So it checks first if it can find the needed file without the sysroot
> business.

I guess we'll have to copy that. Although it doesn't seem quite the right
behaviour, because it might end up picking up a different perl.h that way...

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-04-21 21:13:50 Re: error handling in pqRowProcessor broken
Previous Message Tomas Vondra 2022-04-21 20:45:16 Re: Assert failure in CTE inlining with view and correlated subquery