bificurate static and dynamic libraries builds, to you can optionally only build one

[Super-Genius]

Not sure why this was removed before, why must you demand that both libraries be built, this can default, but why remove the ability to configure it?

[Vollstrecker]

This is exaktly the behaviour that was mitigated with this implementation. You remember log4j and millions of devs that were checking if they are affected as noone knew were it was in?

The libs have names so you can decide what you use and know afterwards. Your patch just means, if the shared lib wasn't found, ignore the problem and use the static. On distros that split lib into separate packages it's trivial to get into such a situation and then a massive bug is found in zlib, packages are updated and your app is still vulnerable because it has a static linked zlib.

If you want a specific way of linkage - specifiy what you want and tell cmake it should search for it, then use the target that gives you what you want. If you don't care about linkage - rethink your job-choice.

And btw. it's only demanded to have both built if you don't specify which one should be used. find_package(ZLIB COMPONENTS static) and noone cares about the shared lib, everything else is best effort to get at least something which leads to the problems noone wants.

[Jj0YzL5nvJ]

How funny, all I care about is the shared library.

[Vollstrecker]

Nice to see that you know what you want. Now tell cmake that you want it shared, and you'll be fine.

[Super-Genius]

Still a very opinionated unusual way to do it and makes it where every other cmake change behaviours in find package, no other package I've ever seen thinks static or dynamic is a component of the package. it's a hack at best. Besides @Vollstrecker youre just one of many contributors. To use the way you're suggesting means that we have to edit 20-30 repos CMakeList.txt file to work around this instead if just passing or setting a global define for it

[Vollstrecker]

Sure it's unusual, but a hack? Both are part of one bigger thing, can be used independ and are Not mandatory to be there. Sounds like components.

And yes other repos need to adapt to new stuff, Like with any other new Release of any other dep. I doubt it's 20 - 30, my rough guess would be 3 digits. But having to do Something ist not a reason to not do it.

Beside the security side of knowing what is included somewhere it's also important to know what licenses are needed to be provided. It's a one-time Change for a long term benefit.

[Super-Genius]

Unusual + messy = Hack. Components have different functionality and different code; static and dynamic libs are configuration options, not components.

All you've done is remove configuration options and expect all the other packages to go along with your opinionated programming style.

That's not good for the open-source community if you're so stubborn about something so simple that you have to have it your way or the highway mentality.

It's Ok, we'll just fork the code for that one silly configuration option that we need.

[Vollstrecker]

Unusual + messy = Hack.

Unusual means only that no many got the idea, so no problem. Messy is a very opinionated word, especially if used to criticize just the enforcement of of clearly stating the intention of what should be done.

Components have different functionality and different code; static and dynamic libs are configuration options, not components.

And I'm sure you have an official source for this statement, you just prefer to let everyone search it for their own.

All you've done is remove configuration options

As now there are ~20% more options - what option are you missing (no, best effort give me something to link is not an option).

and expect all the other packages to go along with your opinionated programming style.

If it's opinionated that you know (and write) what you want to link as carefully as you (should) know what your code does, yes then I'm opinionated. As you call it programming style I ask you, why should I make a difference in programming a lib and programming the build-system for it. Both should be clear, understandable and prevent errors, and linking static without knowing is an error. It's one thing to call code messy that is hard to read/understand, it's another thing to call code messy because you don't align with the reasoning behind design decisions.

That's not good for the open-source community if you're so stubborn about something so simple that you have to have it your way or the highway mentality.

Sure, things like log4j were really good for open-source (there's no bad publicity?). I don't (and don't want to try) understand why you don't want to know how you link against an external lib. If you ship a product you should want to know if you need to bundle a dll. I you build an opensource product/distro/etc. you should want to know if it's enough to just replace an so, or if you need to recompile the whole thing. And don't say there are packagemanagers that do it for you, as noone should give control to something third-party when it's possible to state it clear without external help.

It's Ok, we'll just fork the code for that one silly configuration option that we need.

Sure, add_subdirectory, set<some-options), aliasing a the target is way less work than just changing the target name (and adding COMPONENTS to find_package if you can't control how your deps are built).