Re: [PATCH] Add an ldflags_sl meson build option

On 18.06.25 08:40, Matt Smith (matts3) wrote:
> Yes I understand what you're saying. I know Meson tries to set some of
> these flags. But I want the source of truth for my flags for each target
> type to be outside Meson.  Which Meson is not designed to do.
>
> When you're building many 3^rd  party deps all with different build
> systems and all trying to tweak flags here and there, it introduces much
> better consistency to specify "all targets of a certain type use this
> flag set".  Otherwise you end up having to write logic to filter flags
> per build system/package. And yes I realize we live in an imperfect
> world and packages such as postgres will in fact need to set project-
> specific flags, but this should be an exception.
>
> I have raised an issue on Meson itself: https://github.com/mesonbuild/
> meson/issues/14621 <https://github.com/mesonbuild/meson/issues/14621>
>
> Cmake has functionality whereby you can specify linker flags per target
> type and it will set them accordingly.  Meson doesn't have this type of
> feature and instead sets base flags itself across all targets.

Yeah, I see myself agreeing with the answers on that Meson issue. I
think this is just not how the tool was meant to be used.

> So it would be helpful if postgresql could "drill a hole" as you say to
> shared_library() flags because then at least those flags can be
> overrriden externally just for those targets.
>
> If you don't mind me asking - I assume ldflags_sl exists as a way for
> postgres internally to be able to set flags across all shared libs?

I think this is all legacy from makefiles. With makefiles there isn't a
clear boundary between what variables are internal and external. And at
some point someone thought that it would be useful to document the
LDFLAGS_SL variable as external. But I don't know why anyone would use
it. I can make up some ideas retrospectively, perhaps someone wanted to
play around with -fvisibility or -fPIE or stuff like that. But even
then I would wonder whether it has the right granularity, since you
might need different flags for shared modules versus shared libraries.

That's why I asked you if you had a specific use case for an option to
pass. And then we could have thought about a way to expose that option
in a dedicated way perhaps. But I think this idea that you want to
control all the options yourself is just not the way this is meant to be
working.