Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

missing ZLIB configuration support on Windows [feature request] #259

Open
sav-ix opened this issue May 8, 2017 · 6 comments · May be fixed by #1027
Open

missing ZLIB configuration support on Windows [feature request] #259

sav-ix opened this issue May 8, 2017 · 6 comments · May be fixed by #1027

Comments

@sav-ix
Copy link

sav-ix commented May 8, 2017

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
Copy link

jeking3 commented Nov 23, 2017

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

@sav-ix
Copy link
Author

sav-ix commented Nov 23, 2017

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
Copy link

jeking3 commented Nov 23, 2017

Regarding splitting the configuration to be more flexible, I did that in #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
Copy link
Author

sav-ix commented Nov 23, 2017

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
Copy link

jeking3 commented Nov 23, 2017

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
Copy link
Author

sav-ix commented Nov 23, 2017

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.

@Vollstrecker Vollstrecker linked a pull request Dec 11, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants