Re: meson oddities - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: meson oddities
Date
Msg-id cecbf387-6008-8596-1d9a-c1f96afc9416@dunslane.net
Whole thread Raw
In response to Re: meson oddities  (Andres Freund <andres@anarazel.de>)
Responses Re: meson oddities
List pgsql-hackers
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@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


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


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.


>> Also, why have the CPPFLAGS made their way into the LDFLAGS? That seems
>> wrong.
> Because these days meson treats CPPFLAGS as part of CFLAGS as it apparently
> repeatedly confused build system writers and users when e.g. header-presence
> checks would only use CPPFLAGS. Some compiler options aren't entirely clearly
> delineated, consider e.g. -isystem (influencing warning behaviour as well as
> preprocessor paths).  Not sure if that's the best choice, but it's imo
> defensible.
>

Yes, I get that there is confusion around CPPFLAGS. One of my otherwise
extremely knowledgeable colleagues told me a year or two back that he
had thought the CPP in CPPFLAGS referred to C++ rather that C
preprocessor. 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.

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?


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Error on missing Python module in Meson setup
Next
From: Peter Eisentraut
Date:
Subject: Re: psql: Add command to use extended query protocol