fix(cmake): prioritize discovered zlib headers for brpc sources

[zchuango]

What problem does this PR solve?

Issue Number: resolve #2593

Problem Summary:

When brpc is integrated into a parent CMake project with add_subdirectory, include directories added by the parent project may be inherited by brpc targets.

If one of those directories contains an unrelated header named zlib.h, such as Crypto++'s zlib.h, protobuf's gzip_stream.h may resolve that header instead of the zlib header discovered for the build. This causes protobuf compilation to fail because types such as z_stream are not defined:

/usr/include/google/protobuf/io/gzip_stream.h:93:3: error: 'z_stream' does not name a type

The issue is caused by compile-time header resolution, so linking brpc against the bare z library name does not ensure that protobuf includes the intended zlib header.

What is changed and the side effects?

Changed:

• Find zlib explicitly with find_package(ZLIB REQUIRED).
• Link brpc with the standard CMake target ZLIB::ZLIB instead of the bare library name z.
• Prioritize the discovered zlib include directories for SOURCES_LIB, where protobuf's gzip_stream.h is compiled.
• Keep the include-path adjustment target-scoped so that it does not modify global include directories or affect unrelated parent-project targets.

This allows brpc to use the intended zlib header even when a parent project supplies an inherited include directory containing another zlib.h.

Side effects:

• Performance effects: None expected.
• Breaking backward compatibility: None expected.
• Dependency changes: None. zlib was already required by brpc; this change uses CMake's standard FindZLIB result explicitly.

Verification

The issue was reproduced with a minimal parent CMake project that:

• integrates brpc using add_subdirectory;
• adds an inherited include directory containing Crypto++'s zlib.h;
• builds and links a parent_smoke executable against brpc.

Before this change, the reproduction failed while compiling protobuf's gzip_stream.h with:

error: 'z_stream' does not name a type

After this change, a fresh build of the same collision case completed successfully:

docker exec brpc-2593-dev bash -lc "cmake --build /workspace/screenshot-collision-build --target parent_smoke -j2 && /workspace/screenshot-collision-build/parent_smoke && echo PATCHED_COLLISION_CLEAN_BUILD_OK"

The fresh build completed all 378 steps, linked libbrpc.a and parent_smoke, and ran parent_smoke successfully.

Additional verification:

• Standalone CMake configuration: passed.
• Standalone brpc-static build: passed.
• Parent-project CMake configuration: passed.
• Parent-project parent_smoke compile, link, and execution: passed.
• Collision reproduction with Crypto++'s zlib.h: passed after the change.
• ARM64 cross-compilation and linking: passed.
• ARM64 runtime execution: not performed because QEMU/binfmt was unavailable in the test environment.
• git diff --check: passed.

Check List:

• Please make sure your changes are compilable.
• When providing us with a new feature, it is best to add related tests.
• Please follow [Contributor Covenant Code of Conduct](https://github.com/apache/brpc/blob/master/CODE_OF_CONDUCT.md).

[Copilot]

Pull request overview

This PR addresses a CMake integration issue when bRPC is consumed via add_subdirectory(): inherited include directories from a parent project can cause Protobuf’s gzip_stream.h to pick up an unrelated zlib.h (e.g., Crypto++), breaking compilation. The changes make zlib discovery explicit and attempt to prioritize the intended zlib headers during compilation of bRPC sources.

Changes:

• Add find_package(ZLIB REQUIRED) and link against ZLIB::ZLIB instead of the bare z library name.
• Prepend the discovered zlib include directory(ies) for the SOURCES_LIB object library to avoid header collisions.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
CMakeLists.txt	Explicitly discovers zlib and links with ZLIB::ZLIB to use CMake’s standard zlib integration.
src/CMakeLists.txt	Adjusts include ordering for SOURCES_LIB so Protobuf’s gzip compilation resolves the intended zlib.h.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[wasphin]

This should be addressed at the parent project level by scoping the include paths to the intended modules, rather than modifying brpc's internal header order.

[zchuango]

@wasphin I’m not sure I follow. Are you suggesting that this should be fixed entirely in the parent project, with no changes needed in bRPC?