Summary by CodeRabbit

• New Features
  • Added a user-facing option to provide zlib-compatible target aliases.
• Refactor
  • Public libraries renamed to zlib-ng (shared) and zlib-ng-static (static); naming, versioning, output names and DLL suffix handling standardized.
• Chores
  • Installation/export and generated config outputs updated to publish zlib-ng‑named libraries and symbols.
• Tests
  • Tests, benchmarks and fuzz targets updated to link against zlib‑ng variants with no behavior changes.

Walkthrough

Replace public CMake targets and exports from zlib/zlibstatic to zlib-ng/zlib-ng-static, add zlib-ng::zlib and zlib-ng::zlibstatic aliases, introduce ZLIB_ALIASES option, and update install/export, target properties, symbol/version-script references, and all test/benchmark/fuzz/link targets accordingly.

Changes

Sequence Diagram(s)

Possibly related PRs

• Address deprecated cmake version warning. #1812 — Adds ZLIB_COMPAT and related export/alias behavior used when mapping zlib-ng targets to legacy ZLIB/ZLIBSTATIC EXPORT_NAMEs.

Suggested labels

Build Env, enhancement, cleanup

Suggested reviewers

• nmoinvaz
• Dead2

Pre-merge checks and finishing touches

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Half of the build directories are broken due to lack of updating... Not sure if this is even a good idea as any third-party build scripts will break too.

This will break a lot of downstream projects that rely on the old CMake project names.

This might be relevant:
#723

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.47%. Comparing base (7b29794) to head (7673a22).
⚠️ Report is 1 commits behind head on develop.

@@             Coverage Diff             @@
##           develop    #1970      +/-   ##
===========================================
+ Coverage    81.40%   82.47%   +1.07%     
===========================================
  Files          161      161              
  Lines        13748    13748              
  Branches      3149     3149              
===========================================
+ Hits         11191    11339     +148     
+ Misses        1533     1360     -173     
- Partials      1024     1049      +25     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Half of the build directories are broken due to lack of updating...

Fixed.

This will break a lot of downstream projects that rely on the old CMake project names.

I've added optional aliases for the old names - projects can now use set(ZLIB_ALIASES OFF) to avoid the clash, while existing projects should be unaffected.

This will break a lot of downstream projects that rely on the old CMake project names.

I've added optional aliases for the old names - projects can now use set(ZLIB_ALIASES OFF) to avoid the clash, while existing projects should be unaffected.

This is a good idea and cause less trouble, especially with older CMake versions that can't handle duplicate target names. Eventually, in future major release, we might want to drop the support for short target names as recent releases of stock zlib already support the namespaced target names.

What about the GH issue where the customize the entire name?

What about the GH issue where the customize the entire name?

Customizing the entire name might cause own issues... It might be better for a zlib-ng fork instead of the main repository just to keep things wandering too much and becoming maintaining nightmare.

In minizip-ng I do support specifying a suffix to the project name.

In minizip-ng I do support specifying a suffix to the project name.

When the aliases are disabled, nothing stops from supporting specifying a suffix for a target name, but it might warrant separate PR after this one is merged... Biggest issue with supporting completely different name for targets in zlib-ng is that the new name can clash with any random target in any project and then people come to us complaining things break.

Later CMake versions can already handle duplicate target names in subprojects, so this is mainly for backwards compatibility until we stop supporting old enough CMake versions.

Biggest issue with supporting completely different name for targets in zlib-ng is that the new name can clash with any random target in any project and then people come to us complaining things break.

We can’t fix stupid people.

My point in mentioning that other GH issue is that we should just implement that and these changes in this PR would not be needed.

Biggest issue with supporting completely different name for targets in zlib-ng is that the new name can clash with any random target in any project and then people come to us complaining things break.

We can’t fix stupid people.

My point in mentioning that other GH issue is that we should just implement that and these changes in this PR would not be needed.

We also shouldn't make things easier for stupid people... It's always about choosing what is the best way to implement things, sometimes it's not the one with smallest or least complicated change. I've been software designer and developer for over 40 years and I've had quite a lot of experience with choosing what is the best option of many choices... But in the end it's just one opinion when I'm not the project maintainer.

1. I do prefer that we don't keep the name zlib/zlibstatic all over CMake, those should really only be for zlib-compat mode. So in that way I agree with this PR. ✔️
2. Having the zlib-ng::zlib style namespacing ✔️
3. I would have also liked to have seen support for adding custom aliases like cmake request: please provide an option to give a unique library name on all platforms #723 suggests ❌

What do you think about point 3 @ccawley2011, is this something you would want to implement as well?

@ccawley2011 Would you please rebase this PR, so we can see that it still works after other PRs. And I'd also like your reply on the above question if you could.

This LGTM. Perhaps someone else wants to make a PR to add CMake target aliases

Adding "target aliases" needs proper discussion or it will flood us with complains from people who try to use the feature without knowing the restrictions for target names.

In my professional opinion, we should only allow adding extra suffix to the library base name(s), as that should be enough for portable builds, which would be the biggest user of the feature.

The use case in the linked issue suggests that this might be sufficient since it both renames the target to be different from standard zlib and adds zlib-ng::zlib and zlib-ng::zlibstatic as aliases, but it would be good if @joshtriplett is able to confirm if this is good enough or not.

For portable builds, we need to adjust zlib-ng-config.cmake or zlib-config.cmake so it doesn't reference CMAKE_CURRENT_LIST_DIR, and sets *_INCLUDE_DIRS to both *_BINARY_DIR and *_SOURCE_DIR, where * is either zlibor zlib-ng, in that order ... Then we can export a target, like zlib-portable or zlib-ng-portable, that doesn't exist in normal build. Each target can be associated with a component that can be used with find_package to differentiate types of builds.

A lot of the information is scattered through several sections of various books about CMake, with very little information in actual CMake documentation except notes about deprecated features.

This will make sure find_package finds the portable build before the regular build.