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.