Re: [RFC] building postgres with meson -v8 - Mailing list 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@eisentraut.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@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