AcademySoftwareFoundation
Findminizip-ng.cmake now fully handles library names without trailing…
There was what looked to be an incomplete handoff between Findminizip-ng.cmake and the library CMakeLists.txt file, where there was mechanism to handle the case where a third-party installer had installed minizip-ng in such a way that neither headers nor library has a -ng suffix (and indeed, if you pull down the base minizip-ng from GitHub, it installs its products without suffixes).
Anyway, there was provision in the latter file to handle this case if a certain communication variable was set, but the Findminizip-ng.cmake module wasn't setting that module.
I'd very much welcome criticism from those who understand both cmake in general and the OCIO build system in particular as to whether this is a good way to handle the situation (which ... sometimes I wonder if I'm the only MacPorts user on the planet who uses ASWF tools), or whether some other approach would be more tasteful.
Something similar came up with OpenImageIO and "auto-building" zlib-ng
So, for example, an app that itself uses zlib and OIIO might end up itself using zlib-ng inadvertently. Is that always ok? Maybe it's fine, I just think we need to be confident that this is the behavior we want.
Is minizip_LIBRARY is already defined, is it safe to redefine it to point to the un-suffixed minizip-ng library? I don't know much about minizip-ng; but it seems to me like this is the intended behavior, although I imagine it's possible to end up building software with rpath references to dynamic vanilla minizip libraries in some parts, and dynamic minizip-ng libraries in others, which seems like it might cause trouble...
I feel like maybe the safest thing to do is to only try to link static un-suffixed minizip.a (if minizip_LIBRARY is already set), but I could be overthinking this.
Does macports provide static minizip-ng builds, by any chance?
@JGoldstone thanks for the PR, like @zachlewis I'm not really happy updating minizip_LIBRARY like this. If I'm understanding your original issue correctly, we have an issue when trying to hide the minizip-ng symbols, looking at the conditional I see that we check for minizip-ng_COMPAT which the current Find module we use should set in your case. Can you check if and why this would not be set, maybe there is a bug / edge case we didn't cover.
