Re: meson oddities - Mailing list pgsql-hackers

From Andres Freund
Subject Re: meson oddities
Date
Msg-id 20221114232407.peu4n2wzff3oud4m@awork3.anarazel.de
Whole thread Raw
In response to meson oddities  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: meson oddities
List pgsql-hackers
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?


> 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.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: meson oddities
Next
From: Thomas Munro
Date:
Subject: Re: Suppressing useless wakeups in walreceiver