public inbox for [email protected]
help / color / mirror / Atom feedFrom: Andrew Dunstan <[email protected]>
To: Andres Freund <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: meson oddities
Date: Tue, 15 Nov 2022 08:04:29 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
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
view thread (14+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: meson oddities
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox