ZLIBConfig.cmake.in doesn't honor shared and static build setting

[thokra1]

Affected versions: 1.3.2

When configuring with either shared or static libs turned off, ZLIBConfig.cmake.in will still be configured unconditionally with set(_ZLIB_supported_components "shared" "static"). When looking for the lib using find_package, the default path will then unconditionally try to include() each config in the list, whether it has actually been built or not. That leads to config errors that can't be resolved without patching either the *.in or the configured result. Even when forcing ZLIB_FIND_COMPONENTS, other libraries like ZIP or PNG might look for the ZLIB without providing a component via find_package(ZLIB COMPONENTS ...), so without a working default path, configuration will also fail.

The *.in file should also contain something like set(_ZLIB_supported_components @COMPONENTS@), where @COMPONENTS@ should be filled depending on the values of ZLIB_BUILD_STATIC and ZLIB_BUILD_SHARED.

The most extreme case at the moment is when both are set to false. That will result in no binaries being built and thus, the config file will never be correct. Different issue, but unless a purely header and meta data export is an intended option, we should be forced to build at least one library type (i.e. (BUILD_STATIC || BUILD_SHARED) == true).

[thokra1]

Ah, one little improvement suggestion at the callsite of configure_package_config_file(). Since the config file doesn't use set_and_check or check_required_components, the configure call should be using configure_package_config_file( ... NO_SET_AND_CHECK_MACRO NO_CHECK_REQUIRED_COMPONENTS_MACRO ...) to reduce noise in the config file.

[Vollstrecker]

That's intended behaviour.

• I don't remember the name but I've seen packagings where shared, static and dev where separated. In this case it's possible to have them all built and in the config, but not all installed.
• Imho cmake made a wrong decision with depending on a var to decide whether shared or static libs will be built as distros usually package both they need 2 runs. The configs would have to be adjusted to reflect that.
• Static builds of binaries using the lib should also link to the static lib. As there are different targets for them, extra code would be needed to check what was found if this would depend on how it was built.
• as config-mode is listed in the docs as fallback an unmodified find_package(ZLIB) will first use FindZLIB which unconditionally returns true regardless of what was found. And as this version is the first one that ships a config a modification to explicitly request the config is needed. Listing the wanted components when doing this modification shouldn't be asked too much and makes everything way more predictable.

For the scenario with both builds disabled. Beside a thinkable scenario where users use fetchcontent to retrieve the code to use the sources directly where nothing needs to be build but zconf.h needs to be generated (yes, linking to the static would do the same), someone would need to disable them both. If someone really writes the configure line to not build anything, it's not my responsibility to guess what's really intended. It's the same thing why every find_package call should have REQUIRED listed because it's just plain wrong if someone set's i.e. bzip2 support for minizip and then get's a version without minizip and therefor errors in the later compiles, just because I took his order more like a wish.

For the set_and_check, you're right, while rewriting the need for those was removed but generation wasn't disabled.

[j-schultz]

Maybe I'm misunderstanding, but...

That's intended behaviour.

So configuring ZLIB with -DZLIB_BUILD_SHARED=OFF, installing it and then doing a find_package(ZLIB REQUIRED) causing CMake configuration to fail because of

CMake Error at D:/.../zlib/lib/cmake/zlib/ZLIBConfig.cmake:40 (include):
  include could not find requested file:

    D:/.../zlib/lib/cmake/zlib/ZLIB-shared.cmake

is meant to be intended behaviour? It effectively makes the CMake configuration unusable. That doesn't make sense to me.

[Vollstrecker]

You don't missunderstand.

First: I just installed the configs and put a message(FATAL_ERROR... at the beginning. Just find_package(ZLIB REQUIRED) still uses FindZLIB module. Docs say regarding the basic signature's [CONFIG|NO_MODULE] option:

The MODULE keyword implies that only Module mode can be used to find the package, with no fallback to Config mode

So this should work as expected. OTOH if you build like that and the config returns true, what happens next? Right, you link against ZLIB::ZLIB and get an error because that target doesn't exist. So reports about the config not creating the target will arise and someone asks (again) to create the target as alias for the static one, so noone can rely on what it linked in at the end.

[Vollstrecker]

P.S. I just tried with

find_package(ZLIB REQUIRED COMPONENTS shared)

I get an error because FindZLIB doesn't support components and still is used. I needed to write

find_package(ZLIB CONFIG REQUIRED COMPONENTS shared)

to get the expected error, and as stated before, the config is new in this version, so everyone that wants to use the config must state to use the config, and if they do so it's no problem to also state what they want to use and therefor can rely that everything they want to use is really what they expect.

[thokra1]

That's intended behaviour.

• I don't remember the name but I've seen packagings where shared, static and dev where separated. In this case it's possible to have them all built and in the config, but not all installed.

Oh I can see why that would be beneficial - distribution and dev setups need not have the same build confs at all. Still, that's not the case in the current setup for ZLIB. You install what you build, but the config file doesn't reflect what's installed.

• Imho cmake made a wrong decision with depending on a var to decide whether shared or static libs will be built as distros usually package both they need 2 runs. The configs would have to be adjusted to reflect that.

But it's not CMake's behavior that's the problem here. If you're referring to BUILD_SHARED_LIBS, that's not at play here because all add_library calls are qualified properly. That's all well and good and not the issue.

• Static builds of binaries using the lib should also link to the static lib. As there are different targets for them, extra code would be needed to check what was found if this would depend on how it was built.

That's also not the issue here. It's purely about finding the proper library and if, for instance, I'm building static variants for say a WASM build and a DLL for my Windows distribution, that's absolutely fine. Yes, I could just always build everything and then find_package with either shared or static but if you're assuming that, don't provide means to turn off the respective builds (and ignore BUILD_SHARED_LIBS ofc.).

• as config-mode is listed in the docs as fallback an unmodified find_package(ZLIB) will first use FindZLIB which unconditionally returns true regardless of what was found. And as this version is the first one that ships a config a modification to explicitly request the config is needed. Listing the wanted components when doing this modification shouldn't be asked too much and makes everything way more predictable.

That's not generally true and depends on the value of CMAKE_FIND_PACKAGE_PREFER_CONFIG and I'm no the only one who thinks that this should be the default and MODULE mode should be the fallback. Especially on Windows, this mode is pretty useful (also, Conan enables it by default since version 2.20). In this case, find_dependency as used by libzip and libPNG will redirect to the config modules and then immediately fail, because of the above.

It's the same thing why every find_package call should have REQUIRED listed because it's just plain wrong if someone set's i.e. bzip2 support for minizip and then get's a version without minizip and therefor errors in the later compiles, just because I took his order more like a wish.

Also not generally true - it's perfectly valid to try and find a lib and eval whether package_FOUND or not. There is absolutely no reason to force REQUIRED. ninja does this for example, as do many other libs, but just as a single sample for why this is not generally true:

find_package(GTest)
if(NOT GTest_FOUND)
  include(FetchContent)
  FetchContent_Declare(
      googletest
...

In the above case, REQUIRED would simply make the config fail and prevent the fallback to FetchContent. There are other ways of handling this, sure, but this is absolutely fine.

And again - that's not the issue here.

[Vollstrecker]

That's intended behaviour.

• I don't remember the name but I've seen packagings where shared, static and dev where separated. In this case it's possible to have them all built and in the config, but not all installed.

Oh I can see why that would be beneficial - distribution and dev setups need not have the same build confs at all. Still, that's not the case in the current setup for ZLIB. You install what you build, but the config file doesn't reflect what's installed.

The config reflects the defaults, sure it's inconvenient to change what is built and also need to tell your program what you want to use. Current mode is if nothing is specified it works if everything is there and if not everything is there, make sure everything needed is there. Your suggestion is I found something and hope it is what is needed.

• Imho cmake made a wrong decision with depending on a var to decide whether shared or static libs will be built as distros usually package both they need 2 runs. The configs would have to be adjusted to reflect that.

But it's not CMake's behavior that's the problem here. If you're referring to BUILD_SHARED_LIBS, that's not at play here because all add_library calls are qualified properly. That's all well and good and not the issue.

It's the cause, because if this design choice wouldn't be made, it could be possible to build both variants from one target having static or shared lib as property. Now we can either build only one or need different names and that's the reason for searching 2 different things.

• Static builds of binaries using the lib should also link to the static lib. As there are different targets for them, extra code would be needed to check what was found if this would depend on how it was built.

That's also not the issue here. It's purely about finding the proper library and if, for instance, I'm building static variants for say a WASM build and a DLL for my Windows distribution, that's absolutely fine. Yes, I could just always build everything and then find_package with either shared or static but if you're assuming that, don't provide means to turn off the respective builds (and ignore BUILD_SHARED_LIBS ofc.).

That's the base of everything. You want the static variant and now you are able state that with usage of the static target name. I see no problem when using that name that you also state in your find_package call that you want the static target only. If you pull the new zlib into your env, why not adjusting your project to make use of the new possibilities. In your example you would need a dev tree for your wasm and one for you Windows distribution, so you install all that stuff twice which is a waste of space much higher than the 360k extra for installing both.

I don't know much about wasm, but from your example I guess it only works with static libs. So with current state you would need to build only the static lib and then change your linking to ZLIB::ZLIBStatic if you don't want to alias the target which would mean extra code instead of changing the target name and specifying that you only want to use static.

• as config-mode is listed in the docs as fallback an unmodified find_package(ZLIB) will first use FindZLIB which unconditionally returns true regardless of what was found. And as this version is the first one that ships a config a modification to explicitly request the config is needed. Listing the wanted components when doing this modification shouldn't be asked too much and makes everything way more predictable.

That's not generally true and depends on the value of CMAKE_FIND_PACKAGE_PREFER_CONFIG and I'm no the only one who thinks that this should be the default and MODULE mode should be the fallback. Especially on Windows, this mode is pretty useful (also, Conan enables it by default since version 2.20). In this case, find_dependency as used by libzip and libPNG will redirect to the config modules and then immediately fail, because of the above.

So it's true as setting CMAKE_FIND_PACKAGE_PREFER_CONFIG modifies find_package and I stated unmodified behaviour. I yes, I also think if a config is present it should be used as default.

libpng was already on my list to offer a rework. They differentiate between static and shared already and it's the next logical step to also do this for their deps, that's why I started here as this is one of the foundations. It doesn't make much sense to start on qt and going downwards the dep-chain. Unfortunately I'm not the dev of all that libs because then I could make these changes and release them all together. I guess there are pretty good chances to get the changes in there if there is a release of zlib that provides the mechanisms to use, instead of preparing for a not sheduled release.

libzip wasn't on my list, but it now is. They make use of CMAKE_BUILD_SHARED, so this is a prime example of not knowing what you'll get beforehand. Imagine you request a static build but they link against shared zlib. When you create an installer you need to include zlib as it won't work otherwise, but I'm pretty sure as you link statically, that's not what you want.

And yes, if conan set's this option it will break things if conan also is configured (if possible, don't know conan) to only build one variant. That's a great opportunity to see which packages need adjustments. Sure, you would need to deactivate the option you've set until the other stuff is adapted, but on the long run everyone benefits from having fully predictable builds.

It's the same thing why every find_package call should have REQUIRED listed because it's just plain wrong if someone set's i.e. bzip2 support for minizip and then get's a version without minizip and therefor errors in the later compiles, just because I took his order more like a wish.

Also not generally true - it's perfectly valid to try and find a lib and eval whether package_FOUND or not. There is absolutely no reason to force REQUIRED. ninja does this for example, as do many other libs, but just as a single sample for why this is not generally true:

find_package(GTest)
if(NOT GTest_FOUND)
  include(FetchContent)
  FetchContent_Declare(
      googletest
...

In the above case, REQUIRED would simply make the config fail and prevent the fallback to FetchContent. There are other ways of handling this, sure, but this is absolutely fine.

And again - that's not the issue here.

That's not the issue, right. It was just an explanation to show why I've chosen to design it that way. And sure I know this scenario as I was the one writing it into the docs of gtest. From my example you should see that I was talking about requested feature compiled into the lib, and therefor it is true and it's the same as if you request a static build, tell cmake and it will tell you if it's possible of not. Your example is about additional checks, nothing that influences the final lib at all. In such cases it's totally fine to not require the package to be found and either download it or ignore it at all.

[thokra1]

• Static builds of binaries using the lib should also link to the static lib. As there are different targets for them, extra code would be needed to check what was found if this would depend on how it was built.

That's also not the issue here. It's purely about finding the proper library and if, for instance, I'm building static variants for say a WASM build and a DLL for my Windows distribution, that's absolutely fine. Yes, I could just always build everything and then find_package with either shared or static but if you're assuming that, don't provide means to turn off the respective builds (and ignore BUILD_SHARED_LIBS ofc.).

That's the base of everything. You want the static variant and now you are able state that with usage of the static target name. I see no problem when using that name that you also state in your find_package call that you want the static target only. If you pull the new zlib into your env, why not adjusting your project to make use of the new possibilities. In your example you would need a dev tree for your wasm and one for you Windows distribution, so you install all that stuff twice which is a waste of space much higher than the 360k extra for installing both.

I don't know much about wasm, but from your example I guess it only works with static libs. So with current state you would need to build only the static lib and then change your linking to ZLIB::ZLIBStatic if you don't want to alias the target which would mean extra code instead of changing the target name and specifying that you only want to use static.

Yep, that's part of my current workaround for every platform where I use static builds (and with WASM, that's still preferred in general due to how dynamic linking works there). I patch the CMakeLists.txt, the *.config.in and alias the library from ZLIB::ZLIB to ZLIB::ZLIBSTATIC. That is currently the only way to get a proper build when using PNG and ZIP because neither respects the ZLIB::ZLIBSTATIC target as of yet (as you already kinda noted). However, the only work I should be doing, IMHO, is the aliasing - I shouldn't have to patch ZLIB just because I change a config option to false.

• as config-mode is listed in the docs as fallback an unmodified find_package(ZLIB) will first use FindZLIB which unconditionally returns true regardless of what was found. And as this version is the first one that ships a config a modification to explicitly request the config is needed. Listing the wanted components when doing this modification shouldn't be asked too much and makes everything way more predictable.

That's not generally true and depends on the value of CMAKE_FIND_PACKAGE_PREFER_CONFIG and I'm no the only one who thinks that this should be the default and MODULE mode should be the fallback. Especially on Windows, this mode is pretty useful (also, Conan enables it by default since version 2.20). In this case, find_dependency as used by libzip and libPNG will redirect to the config modules and then immediately fail, because of the above.

So it's true as setting CMAKE_FIND_PACKAGE_PREFER_CONFIG modifies find_package and I stated unmodified behaviour. I yes, I also think if a config is present it should be used as default.

Right, and currently, whether that will work or not depends on both ZLIB build settings and calling find_package with the right options. That's all I'm saying. To quote the CMake docs on find_package:

The above is a reduced form of the basic signature. Where possible, projects should find packages using this form.

Once you flip either build setting, that guideline goes out the window because it simply can't work they way it's currently written.

libpng was already on my list to offer a rework. They differentiate between static and shared already and it's the next logical step to also do this for their deps, that's why I started here as this is one of the foundations. It doesn't make much sense to start on qt and going downwards the dep-chain. Unfortunately I'm not the dev of all that libs because then I could make these changes and release them all together. I guess there are pretty good chances to get the changes in there if there is a release of zlib that provides the mechanisms to use, instead of preparing for a not sheduled release.

libzip wasn't on my list, but it now is. They make use of CMAKE_BUILD_SHARED, so this is a prime example of not knowing what you'll get beforehand. Imagine you request a static build but they link against shared zlib. When you create an installer you need to include zlib as it won't work otherwise, but I'm pretty sure as you link statically, that's not what you want.

In cases where ZLIB is built as a shared lib (e.g. on Windows for reasons), it's ofc copied at build time and distributed properly at install time. In fully static builds (like WASM), everything is linked into the binary as expected.

PNG requires ZLIB unconditionally in both builds and exports, ZIP requires ZLIB during builds and only looks for dependencies at config time when BUILD_SHARED_LIBS was on. However, none of that has any bearing on linking, except that there is no proper way to tell both libs to look for ZLIB::ZLIBSTATIC instead of ZLIB::ZLIB for their link interface when we build everything statically - it's not an issue when ZLIB is built as a shared lib though.

The old find modules would always resolve both static and shared libs into the same target (ZLIB::ZLIB) based on the value of ZLIB_USE_STATIC_LIBS since CMake 3.24, so introducing ZLIB::ZLIBSTATIC is almost like a breaking change - one I understand and support, but still. For now, aliasing ZLIB depending on what is built for the target platform is pretty much the only thing we can do - unless we manually create imported targets and don't rely on find_package at all, which is definitely not the way.

---

In summation, all I'm asking for is that build options don't break config modules and that I'm not forced to do find_package(ZLIB REQUIRED COMPONENTS shared CONFIG) (or static) when a simple find_package(ZLIB REQUIRED) would do - especially with CMAKE_FIND_PACKAGE_PREFER_CONFIG enabled.

The fix would entail just 2 new lines and one adaptation:

# CMakeLists.txt
...
if(ZLIB_BUILD_SHARED)
    list(APPEND COMPONENTS [["shared"]])
....
if(ZLIB_BUILD_STATIC)
    list(APPEND COMPONENTS [["static"]])
....

# zlibConfig.cmake.in
...
set(_ZLIB_supported_components @COMPONENTS@)
...

That handles both cases where an invalid component is specified by the user and the case where find_package is called without components. And the defaults (shared and static enabled) works just the way is does now. Only the pathological case where both are turned off will not trigger an abort when not specifying any components - but as I said above, IMHO, building ZLIB without at least one library output doesn't make any sense anyway.

For other libs, we need to be able to specify that they should look for ZLIB::ZLIBSTATIC if we want to be able to just use libs like PNG and ZLIB together out of the box - that's nothing ZLIB can fix.

[Vollstrecker]

Yep, that's part of my current workaround for every platform where I use static builds (and with WASM, that's still preferred in general due to how dynamic linking works there). I patch the CMakeLists.txt, the *.config.in and alias the library from ZLIB::ZLIB to ZLIB::ZLIBSTATIC. That is currently the only way to get a proper build when using PNG and ZIP because neither respects the ZLIB::ZLIBSTATIC target as of yet (as you already kinda noted). However, the only work I should be doing, IMHO, is the aliasing - I shouldn't have to patch ZLIB just because I change a config option to false.

I guess you're doing this before searching for png and zip. Congratulations, you ensured that if I, that has both variants installed, am able to build your project. And yes, I am aware that you as an early adopter will have to place such a workaround until projects up the dep-chain adopt this, but this inconvenience will hopefully be solved within a year. As statet png is the next on my list and will be started tomorrow, zip will be next, just because you mentioned it here.

Right, and currently, whether that will work or not depends on both ZLIB build settings and calling find_package with the right options. That's all I'm saying. To quote the CMake docs on find_package:

The above is a reduced form of the basic signature. Where possible, projects should find packages using this form.

Once you flip either build setting, that guideline goes out the window because it simply can't work they way it's currently written.

Sure it is, on the high Altair of preditabillity this one needs to be adjusted. I wouldn't be surprised, if more projects adopt this, there will be some new cmake policy to reflect this. But to be honest, specifying what you want and getting this seems worth the work. Plus the fact that almost all Linux users won't see a difference as the configs are almost everywhere inside the dev package beside the static lib. I remember a time where many issues where opened to get cmake support into packages, now the time where issues are opened for predictable cmake support is demanded, starts.

libpng was already on my list to offer a rework. They differentiate between static and shared already and it's the next logical step to also do this for their deps, that's why I started here as this is one of the foundations. It doesn't make much sense to start on qt and going downwards the dep-chain. Unfortunately I'm not the dev of all that libs because then I could make these changes and release them all together. I guess there are pretty good chances to get the changes in there if there is a release of zlib that provides the mechanisms to use, instead of preparing for a not sheduled release.
libzip wasn't on my list, but it now is. They make use of CMAKE_BUILD_SHARED, so this is a prime example of not knowing what you'll get beforehand. Imagine you request a static build but they link against shared zlib. When you create an installer you need to include zlib as it won't work otherwise, but I'm pretty sure as you link statically, that's not what you want.

In cases where ZLIB is built as a shared lib (e.g. on Windows for reasons), it's ofc copied at build time and distributed properly at install time. In fully static builds (like WASM), everything is linked into the binary as expected.

That's what I mean. In your case you build only static and can be sure to link against it. In my setup, I use just system-provided stuff and needed to hope to get what I expected. I could have linked against a shared lib without knowing and therefor don't include it in an installer.

PNG requires ZLIB unconditionally in both builds and exports, ZIP requires ZLIB during builds and only looks for dependencies at config time when BUILD_SHARED_LIBS was on. However, none of that has any bearing on linking, except that there is no proper way to tell both libs to look for ZLIB::ZLIBSTATIC instead of ZLIB::ZLIB for their link interface when we build everything statically - it's not an issue when ZLIB is built as a shared lib though.

It's exactly that. Why should I link against a static libpng when I need to include the shared zlib anyways. And sure there is a proper way to look for static zlib. Take a look at how it's done in minizip. You can link against MINIZIP::MINIZIPStatic and you'll also link against ZLIB::ZLIBStatic, and if one of them isn't found you'll get an error.

The old find modules would always resolve both static and shared libs into the same target (ZLIB::ZLIB) based on the value of ZLIB_USE_STATIC_LIBS since CMake 3.24, so introducing ZLIB::ZLIBSTATIC is almost like a breaking change - one I understand and support, but still. For now, aliasing ZLIB depending on what is built for the target platform is pretty much the only thing we can do - unless we manually create imported targets and don't rely on find_package at all, which is definitely not the way.

zlibs cmake is intentionally made for also supporting older versions, and in these older versions it is unpredictable. I'm glad to hear that you understand the intention, and I'm sure over time this will sort out as more projects adopt this new way of doing this. In the meantime you could use the current FindZLIB, or as you already do, implement this little workaround. I also dislike having to adjust to stuff that changed, and I recognize that it's late to start this, but as the germans say: "Better late than never".

In summation, all I'm asking for is that build options don't break config modules and that I'm not forced to do find_package(ZLIB REQUIRED COMPONENTS shared CONFIG) (or static) when a simple find_package(ZLIB REQUIRED) would do - especially with CMAKE_FIND_PACKAGE_PREFER_CONFIG enabled.

I know what you're asking. You've seen that you prefer addition of 32 letters (plus = ON) instead of 24? What happens if everything goes like planned and libpng offers both variants, too? You need to turn of one like you do now because zlib reports everything found and you'll get an error because pngStatic links on zlibStatic.

That handles both cases where an invalid component is specified by the user and the case where find_package is called without components. And the defaults (shared and static enabled) works just the way is does now. Only the pathological case where both are turned off will not trigger an abort when not specifying any components - but as I said above, IMHO, building ZLIB without at least one library output doesn't make any sense anyway.

I think we can agree on not talking about deactivating both. If someone does this, the trouble is honestly earned. But your requested change won't change anything in regards of predictabillity as still the projects would need to either alias something or proper specify what they link against, and if they specify it in the linker line, it's not asked too much to also only search for that.

For other libs, we need to be able to specify that they should look for ZLIB::ZLIBSTATIC if we want to be able to just use libs like PNG and ZLIB together out of the box - that's nothing ZLIB can fix.

Nope, that's something a dev can fix. And as stated, at least for your examples, I'm going to do it. I just didn't do it yet because a) most devs refuse to change such things for something that's not released yet and b) because after the release people realized that stuff in develop is released some time and now see they are not prepared. When I started this rework, there have been some mentions of maybe upcoming problems and they are mostly solved. It wouldn't have changed my mind about this, but at least I would have now the time to work on other packages to make them compatible.

[thokra1]

Yep, that's part of my current workaround for every platform where I use static builds (and with WASM, that's still preferred in general due to how dynamic linking works there). I patch the CMakeLists.txt, the *.config.in and alias the library from ZLIB::ZLIB to ZLIB::ZLIBSTATIC. That is currently the only way to get a proper build when using PNG and ZIP because neither respects the ZLIB::ZLIBSTATIC target as of yet (as you already kinda noted). However, the only work I should be doing, IMHO, is the aliasing - I shouldn't have to patch ZLIB just because I change a config option to false.

I guess you're doing this before searching for png and zip. Congratulations, you ensured that if I, that has both variants installed, am able to build your project. And yes, I am aware that you as an early adopter will have to place such a workaround until projects up the dep-chain adopt this, but this inconvenience will hopefully be solved within a year. As statet png is the next on my list and will be started tomorrow, zip will be next, just because you mentioned it here.

Right, and currently, whether that will work or not depends on both ZLIB build settings and calling find_package with the right options. That's all I'm saying. To quote the CMake docs on find_package:
The above is a reduced form of the basic signature. Where possible, projects should find packages using this form.
Once you flip either build setting, that guideline goes out the window because it simply can't work they way it's currently written.

Sure it is, on the high Altair of preditabillity this one needs to be adjusted. I wouldn't be surprised, if more projects adopt this, there will be some new cmake policy to reflect this. But to be honest, specifying what you want and getting this seems worth the work. Plus the fact that almost all Linux users won't see a difference as the configs are almost everywhere inside the dev package beside the static lib. I remember a time where many issues where opened to get cmake support into packages, now the time where issues are opened for predictable cmake support is demanded, starts.

libpng was already on my list to offer a rework. They differentiate between static and shared already and it's the next logical step to also do this for their deps, that's why I started here as this is one of the foundations. It doesn't make much sense to start on qt and going downwards the dep-chain. Unfortunately I'm not the dev of all that libs because then I could make these changes and release them all together. I guess there are pretty good chances to get the changes in there if there is a release of zlib that provides the mechanisms to use, instead of preparing for a not sheduled release.
libzip wasn't on my list, but it now is. They make use of CMAKE_BUILD_SHARED, so this is a prime example of not knowing what you'll get beforehand. Imagine you request a static build but they link against shared zlib. When you create an installer you need to include zlib as it won't work otherwise, but I'm pretty sure as you link statically, that's not what you want.

In cases where ZLIB is built as a shared lib (e.g. on Windows for reasons), it's ofc copied at build time and distributed properly at install time. In fully static builds (like WASM), everything is linked into the binary as expected.

That's what I mean. In your case you build only static and can be sure to link against it. In my setup, I use just system-provided stuff and needed to hope to get what I expected. I could have linked against a shared lib without knowing and therefor don't include it in an installer.

PNG requires ZLIB unconditionally in both builds and exports, ZIP requires ZLIB during builds and only looks for dependencies at config time when BUILD_SHARED_LIBS was on. However, none of that has any bearing on linking, except that there is no proper way to tell both libs to look for ZLIB::ZLIBSTATIC instead of ZLIB::ZLIB for their link interface when we build everything statically - it's not an issue when ZLIB is built as a shared lib though.

It's exactly that. Why should I link against a static libpng when I need to include the shared zlib anyways. And sure there is a proper way to look for static zlib. Take a look at how it's done in minizip. You can link against MINIZIP::MINIZIPStatic and you'll also link against ZLIB::ZLIBStatic, and if one of them isn't found you'll get an error.

The old find modules would always resolve both static and shared libs into the same target (ZLIB::ZLIB) based on the value of ZLIB_USE_STATIC_LIBS since CMake 3.24, so introducing ZLIB::ZLIBSTATIC is almost like a breaking change - one I understand and support, but still. For now, aliasing ZLIB depending on what is built for the target platform is pretty much the only thing we can do - unless we manually create imported targets and don't rely on find_package at all, which is definitely not the way.

zlibs cmake is intentionally made for also supporting older versions, and in these older versions it is unpredictable. I'm glad to hear that you understand the intention, and I'm sure over time this will sort out as more projects adopt this new way of doing this. In the meantime you could use the current FindZLIB, or as you already do, implement this little workaround. I also dislike having to adjust to stuff that changed, and I recognize that it's late to start this, but as the germans say: "Better late than never".

In summation, all I'm asking for is that build options don't break config modules and that I'm not forced to do find_package(ZLIB REQUIRED COMPONENTS shared CONFIG) (or static) when a simple find_package(ZLIB REQUIRED) would do - especially with CMAKE_FIND_PACKAGE_PREFER_CONFIG enabled.

I know what you're asking. You've seen that you prefer addition of 32 letters (plus = ON) instead of 24? What happens if everything goes like planned and libpng offers both variants, too? You need to turn of one like you do now because zlib reports everything found and you'll get an error because pngStatic links on zlibStatic.

That handles both cases where an invalid component is specified by the user and the case where find_package is called without components. And the defaults (shared and static enabled) works just the way is does now. Only the pathological case where both are turned off will not trigger an abort when not specifying any components - but as I said above, IMHO, building ZLIB without at least one library output doesn't make any sense anyway.

I think we can agree on not talking about deactivating both. If someone does this, the trouble is honestly earned. But your requested change won't change anything in regards of predictabillity as still the projects would need to either alias something or proper specify what they link against, and if they specify it in the linker line, it's not asked too much to also only search for that.

For other libs, we need to be able to specify that they should look for ZLIB::ZLIBSTATIC if we want to be able to just use libs like PNG and ZLIB together out of the box - that's nothing ZLIB can fix.

Nope, that's something a dev can fix. And as stated, at least for your examples, I'm going to do it. I just didn't do it yet because a) most devs refuse to change such things for something that's not released yet and b) because after the release people realized that stuff in develop is released some time and now see they are not prepared. When I started this rework, there have been some mentions of maybe upcoming problems and they are mostly solved. It wouldn't have changed my mind about this, but at least I would have now the time to work on other packages to make them compatible.

Forgive me, but most of what you're saying has nothing to do with the fact that you can break ZLIB's config module by slightly deviating from the the default build settings. It's pretty clear that you don't see any value in my proposal so, nvm.

[Vollstrecker]

Forgive me, but most of what you're saying has nothing to do with the fact that you can break ZLIB's config module by slightly deviating from the the default build settings. It's pretty clear that you don't see any value in my proposal so, nvm.

Nothing to forgive, it's always worth a try. Breaking a config that didn't exist before sound a bit hard to me.

But while shoveling some snow I got an idea for a compromise. As you will have the same issue when I went on with libpng, just one step up the ladder, what do you think about introducing a new var? Let's call it CMAKE_PREFFERRED_COMPONENTS. This one can be included by cmake (I would talk to them) and with that one you can preselect the components you want. So in short if this var is set, it will be treated as you would've set it in every find_package call. So my goal of predictability is reached as it still won't change current behaviour, but you are able to select everything you need in one place.

[j-schultz]

Even if the issue was closed, I'm still not sure how to proceed.

We have various dependencies that themselves depend on zlib, and we usually build them statically but also sometimes need to be able to provide dynamic dependencies. Usually this looks somewhat like this:

find_package(ZLIB)

if(ZLIB_FOUND)
        if(TARGET ZLIB::ZLIBSTATIC)
            target_link_libraries(foo ZLIB::ZLIBSTATIC)
        else()
            target_link_libraries(foo ZLIB::ZLIB)
        endif()
endif()

The first line now results in a CMake error that we cannot recover from. How would I implement this kind of dependency "discovery" with the new release?

[Vollstrecker]

• find_package(ZLIB COMPONENTS static) if you want static
• find_package(ZLIB COMPONENTS shared) if you want shared
• find_package(ZLIB COMPONENTS shared static) if you want both

at least if you've built build what you want. The third line should do the same as the one you have already, if you've built both.

As a bonus, the rest of the code isn't needed, because you already know the target exists.

[j-schultz]

But that's the thing - it's no longer possible to figure this out dynamically, in a way that prefers one build over another but doesn't error out if the preferred build is not available. There's no more possibility to say "I want zlib, no matter if it's static or dynamic" because all three of these suggestions will cause a CMake error if one of the listed components is not available. I fully understand that this behaviour might not even be desirable in every scenario, but that should be on the caller to decide. It seems bad practice to me that simply calling find_package can cause an unrecoverable CMake error if the component is not even marked as REQUIRED.