One way to make sure tests are built when building zlib standalone:

if (${CMAKE_PROJECT_NAME} STREQUAL zlib)
  option(ZLIB_ENABLE_TESTS "Set to ON to enable the ZLIB tests" ON)
else ()
  option(ZLIB_ENABLE_TESTS "Set to ON to enable the ZLIB tests" OFF)
endif ()

It takes an extra second or two for the tests to link and run. Is this worth the effort? When you run cmake --build . --target install you don't get any of the test executables installed. What's the use case?

One case is that projects using the zlib as submodule (via CMakeLists.txt) might have the same target names, and CMake does not allow duplicate target names. "example" is VERY generic. If they aren't excluded, at least rename the test targets as zlib_example, zlib_example64 ?

That is quite reasonable, thanks for the addition info. If zlib cmake was in a cmake project() would that properly scope it?

Not sure I understand what you mean by that, but if you mean that a top level project including zlib with add_subdirectory(path/to/zlib EXCLUDE_FROM_ALL), it would work nicely.

According to the CMake docs, it's best to use a "include(CTest)" and put tests inside an "if(BUILD_TESTING)" block

I absolutely can't believe this issue is not fixed yet. I have included zlib as submodule and the example test is failing (for whatever reason). And there is no way to disable it. What a shame.

I'm also pretty flabbergasted that this is still a problem 6 years after the issue was raised. I'm using zlib as a git submodule in an embedded project with zero support for executables. And it is seriously annoying to have to manually comment out the section trying to build the executables to make it build and then have to revert it again to be able to submit changes to the parent module.

7 years... still no fix?

@madler: Can you look it?

I guess you meant madler 🙈 , right?

How am I supposed to know what the right thing to do is? It seems like every time I apply a patch to fix someone's cmake problem, someone else's cmake workflow gets screwed up.

I have included zlib as submodule and the example test is failing (for whatever reason).

The "whatever reason" may be important. example is there in the first place to test for basic problems with the zlib build. How exactly is it failing?

This leads me to think that the example test should not in fact be made optional, since there should be at least a minimal test that the zlib build is correct.

I have included zlib as submodule and the example test is failing (for whatever reason).

The "whatever reason" may be important. example is there in the first place to test for basic problems with the zlib build. How exactly is it failing?

This leads me to think that the example test should not in fact be made optional, since there should be at least a minimal test that the zlib build is correct.

Yeah what you're saying is true. But as a consumer of zlib (via submodule), I don't want to run any zlib tests during builds. Only zlib devs should even be running these tests. But I agree that having a test fail indicates a deeper problem.

Unfortunately I don't have context anymore, since I've moved away from the project that used zlib. But it seems that a simple change could unblock a lot of people.

https://github.com/libjxl/libjxl/actions/runs/7671453687/job/20909823847

Here's an example of a test in zlib failing for us when using msan. It is flaky.

https://github.com/libjxl/libjxl/actions/runs/7671453687/job/20909823847

Here's an example of a test in zlib failing for us when using msan. It is flaky.

That is with 1.2.11. Use the most recent version (1.3.1).

6201f89 added the requested option.