missing ZLIB configuration support on Windows [feature request]

[sav-ix]

Currently MSYS2, a shell port on Windows, provide a wide range of *unix Developer's tools (see msys2 Wiki and MSYS2 at SourceForge.net, etc.). Among other things it allow to process ./configure scripts of autotools or autotools-like builds systems, generate Makefiles for specified configuration and build them using GNU make. Thus many notable Open Source libraries (e.g. libiconv, ICU, MPIR, etc.) has MSYS2 toolchains in its build systems.

If ZLIB would provide MSYS2 support, it allow to make its configuration more flexible (split builds to <Debug|Release><Shared|Static> configurations, as implemented for other platforms), and simplify build, install and test tasks.

Alexander

[jeking3]

If the CMake build environment properly supported MSYS2 would that be sufficient? I'm working on that.

[sav-ix]

MSYS2 provide CMake binaries too. But since CMake port available for Windows on it's homepage, it could be used without other dependencies, like MSYS2. The other question, what ZLIB users will prefer as makefile generator: unix shell or CMake.

[jeking3]

Regarding splitting the configuration to be more flexible, I did that in https://github.com/madler/zlib/pull/315, allowing the builds to work as they have in the past, but if you specify -DBUILD_STATIC_AND_SHARED=OFF then it switching to honoring -DBUILD_SHARED_LIBS like any other program; and CMake already honors -DCMAKE_BUILD_TYPE. So there's a solution out there for that.

I would actually recommend deprecating the static+shared combo build, since it makes building on some platforms more difficult. If that PR is accepted then in a future release the default for this option to build shared and static together can be changed to OFF.

Given msys2 has cmake (currently at v3.6.2), I am working on an appveyor script that will ensure builds on msys2 work and stay working. The combination of both of these should satisfy your needs?

[sav-ix]

CMake support for ZLIB is useful, although it does not suit everyone. Since CMake is fully standalone, there is no reason in additional layer (MSYS2) between it and ZLIB. The most common solution is to allow ZLIB Users to chose makefile generator between CMake ans unix shell (MSYS2), instead of mixing them.

[jeking3]

Projects should not have two build systems. It is an additional maintenance cost for anyone working on the project. The configure script is complex with many branches. If the project standardizes on cmake as a build delivery vehicle, the cost of maintenance will go down.

[sav-ix]

Using multiple build systems in one project has both advantages and disadvantages. Some notable OSS projects use two or even three build systems, most only one. But if ZLIB Community would consider to move completely to CMake, then there would be no need in usage of MSYS2 for ZLIB build at all.