Provide ZLIB::ZLIB as a CMake alias when shared libraries are disabled

[ccawley2011]

This matches the behaviour of FindZLIB from standard CMake installations.

[Vollstrecker]

Point 1: Why do you checkif the target exists, if you could check for the option if the target should be created?

Point 2: FindZLIB tries to provide something, but the point in the named targets is to know what you link against. If you you want a static linking, there's a target. Imagine you expect dynamic linking and want to install the dll in your script, but there is none, you would have to add additional checks. Yes, with your changes in the config you mimic the old behaviour, but if someone includes the sources Idmeand them to check if there are changes. Such situations happen with apis all the time, so it's not asked too much to check if all the targets are still correct (and if you link against ZLIB:::ZLIB and don't set any options you'll have no problems in this case), and instead of checking for existing dll's I consider it better to check for the version and just use the right targets in you build instead of hoping to get sommething.

[Mizux]

ZLIB_USE_STATIC_LIBS
Added in version 3.24.
Set this variable to ON before calling find_package(ZLIB) to look for static libraries. Default is OFF.

from: https://cmake.org/cmake/help/latest/module/FindZLIB.html

So having ZLIB::ZLIB fallback to zlibstatic when using ExternalProject/FetchContent/add_subdirectory() could be a reasonable behaviour imho...
also if consumer require to know if it is a static or a shared lib (which also can be see as an integration implementation details) you could still use $<STREQUAL:$<TARGET_PROPERTY:ZLIB::ZLIB,TYPE>,SHARED_LIBRARY>...

[Vollstrecker]

So having ZLIB::ZLIB fallback to zlibstatic when using ExternalProject/FetchContent/add_subdirectory() could be a reasonable behaviour imho...

You mean when you
a) use FindZLIB and get no result or
b) when you unconditionally include the lib like you mentioned or
c) when using the new automatism of find_package (didn't test, but from reading it's the same as option a

So in all 3 cases you can set ZLIB_BUILD_SHARED to OFF before doing this and alias this yourself.

also if consumer require to know if it is a static or a shared lib (which also can be see as an integration implementation details) you could still use $<STREQUAL:$<TARGET_PROPERTY:ZLIB::ZLIB,TYPE>,SHARED_LIBRARY>...

Because FindZLIB line 254 sets it to UNKNOWN and you'll never know?

But if you mention genex as an point, what about $<If $<TARGET_EXISTS:ZLIB::ZLIBSTATIC>, ZLIB::ZLIBSTATIC, ZLIB::ZLIB>?

[Neustradamus]

@madler: Have you seen this PR?

[Mizux]

Food for thought https://alexreinking.com/blog/building-a-dual-shared-and-static-library-with-cmake.html

[Vollstrecker]

I usually don't comment such things, but there are some problems with this text:

• He always refers to "our design criteria" not explaining who's or where they can be viewed or why someone else should care about them.
• He states that users have to build both version which is time consuming, which is wrong for zlib as you can turn one or even both off. At the same time he refers to vcpkg which by default builds release and debug which is usually not needed.
• Regarding turning off one version to save time: He states to have a function to turn that switch, so setting a var is good in that case. Small difference in that case: setting ZLIB_BUILD_SHARED can be read afterwards while the CMAKE_BUILD_SHARED in that function is inaccessible afterwards.
• He states that the type of the library is always determined, which is true in the current state but wrong when using findZLIB or when merging this PR. Atm. we have the same problem with minizip because bz2 is not specific with this and it's possible to link a static libminizip with a shared bz2 or vice versa without knowing it.
• He also refers to add_subdirectory or fetch_content. For both a function would be needed to set CMAKE_BUILD_SHARED only for the included project while atm. it's just setting a var to choose and include the project the have the same effect.
• He also states that users usually want on one variant and completely ignores that packagers for distros usually build both variants. In his example it's not even easy to have them both installed and I'm pretty sure distros running the complete configure-process consumes more time than users building a second lib (we're not talking about monsters like Qt where this would make a difference measured in hours not minutes).
• He talks about an ideal world where users choose easily what they want. My ideal world is you link against a shared libminizip that links against a shared zlib and a shared bz2 OR you link against a static libminizip that links against static zlib and static bz2 just by choosing the target minizip or minizip-static instead of making that setting for all 3 of them.