I am assuming that zlibstatic is the static version of zlib. I am confused as to how building zlibstatic is controlled. From what I am seeing

add_library(zlib SHARED ${ZLIB_SRCS} ${ZLIB_ASMS} ${ZLIB_DLL_SRCS} ${ZLIB_PUBLIC_HDRS} ${ZLIB_PRIVATE_HDRS})
add_library(zlibstatic STATIC ${ZLIB_SRCS} ${ZLIB_ASMS} ${ZLIB_PUBLIC_HDRS} ${ZLIB_PRIVATE_HDRS})

is outside any control block (compiler- or platform-specific, e.g. CYGWIN, MSVC, MINGW etc., installation routine etc.) so it means that it is always built regardless of whether BUILD_SHARED_LIBS is set or not.

If this is indeed the case I suggest making the process optional depending on the BUILD_SHARED_LIBS (if set, static will not be built, otherwise it will) or some other variable in case the case when both versions of the library are required. Example:

if(BUILD_SHARED_LIBS)
	add_library(zlib SHARED ${ZLIB_SRCS} ${ZLIB_ASMS} ${ZLIB_DLL_SRCS} ${ZLIB_PUBLIC_HDRS} ${ZLIB_PRIVATE_HDRS})
else()
	add_library(zlibstatic STATIC ${ZLIB_SRCS} ${ZLIB_ASMS} ${ZLIB_PUBLIC_HDRS} ${ZLIB_PRIVATE_HDRS})
endif()

Further tweaks are necessary since the code above produces binary such as zlibd1, which should not be possible (adding release AND debug suffix to the binary's name). It is just a demonstration of what I am describing.

The reason why I am suggesting this is simple: a project should not build specific binaries unless told so. In my case I don't want to build the static version. While zlib is small, building unwanted binaries adds to the complexity of a build process that depends on zlib including build time, sources of error and last but not least automated deployment (e.g. copying all *.lib files from the binary directory by a simple file(GLOB ...) call and automatically including them into another project; currently not possible without extra work since both zlib1.lib/zlibd.lib and zlibstatic/zlibstaticd.lib (Windows platforms) are being captured).