Re: meson oddities

Hi,

On 2022-11-15 08:04:29 -0500, Andrew Dunstan wrote:
> On 2022-11-14 Mo 18:24, Andres Freund wrote:
> > Hi,
> >
> > On 2022-11-14 17:41:54 -0500, Andrew Dunstan wrote:
> >> Here's a couple of things I've noticed.
> >>
> >>
> >> andrew(at)ub22:HEAD $ inst.meson/bin/pg_config --libdir --ldflags
> >> /home/andrew/pgl/pg_head/root/HEAD/inst.meson/lib/x86_64-linux-gnu
> >> -fuse-ld=lld -DCOPY_PARSE_PLAN_TREES -DRAW_EXPRESSION_COVERAGE_TEST
> >> -DWRITE_READ_PARSE_PLAN_TREES
> >>
> >>
> >> Are we really intending to add a new subdirectory to the default layout?
> >> Why is that x84_64-linux-gnu there?
> > It's the platform default on, at least, debian derived distros - that's how
> > you can install 32bit/64bit libraries and libraries with different ABIs
> > (e.g. linking against glibc vs linking with musl) in parallel.
> >
> > We could override meson inferring that from the system if we want to, but it
> > doesn't seem like a good idea?
> >
>
> That's a decision that packagers make. e.g. on my Ubuntu system
> configure has been run with:
>
> --libdir=${prefix}/lib/x86_64-linux-gnu

Sure - but that doesn't mean that it's a good idea to break the distribution's
layout when you install from source.

> Incidentally, Redhat flavored systems don't use this layout. they have
> /lib and /lib64, so it's far from universal.

Meson infers that and uses lib64 as the default libdir.

> But ISTM we shouldn't be presuming what packagers will do, and that
> there is some virtue in having a default layout under ${prefix} that is
> consistent across platforms, as is now the case with autoconf/configure.

I don't think it's a virtue to break the layout of the platform by
e.g. installing 64bit libs into the directory containing 32bit libs.

> And the authors of meson seem to have labored under a similar
> misapprehension, so they use 'cpp' instead of 'cxx' like just about everyone
> else.

Yea, not a fan of that either. I don't think it was a misapprehension, but a
decision I disagree with...

> But it's less clear to me that a bunch of defines belong in LDFLAGS.
> Shouldn't that be only things that ld itself will recognize?

I don't think there's a clear cut line what is for ld and what
isn't. Including stuff that influences both preprocessor and
linker. -ffreestanding will e.g. change preprocessor, compiler (I think), and
linker behaviour.

Greetings,

Andres Freund