fix: Remove zconf.h from source repo #740
Conversation
It has to be regenerated anyway, either through configure or CMake. Having it in the repo means that the CMake build will rename it, dirtying the repo when used as a submodule. A simpler alternative to madler#519
|
@Togtja, JFYI. |
|
This would then make direct build from within visual studio file when one clones and directly invokes msbuild using |
|
As I said before, not everyone uses or likes CMake, also not everyone can run ./configure (Windows users) and build directly with Visual Studio and this change would actually break them as people expect to be able to clone and then instantly build zlib without any other manual steps to take. And by people I mean companies and individual developers. |
|
Yeah, for Windows users I would recommend not using cmake for zlib and instead the solution files in contrib/vstudio (which allows for building x86, x64, ARM, and ARM64). Besides Windows now also has WSL, which is Linux as well so they can also cross compile zlib for linux using WSL as well (using ./configure without needing a VM which can also cross compile x86, x64, ARM, and ARM64). Then for osx, one could start up even a cheap macbook pro early 2015 model and build zlib with it too (and cross compile for ARM64 as well because it is x64). btw #732 shows how I done the above (and also used those artifacts from it to generate a nuget package for consuming it in .NET applications. |
|
In my case, we're building everything statically in a large project, using CMake and git submodules. The status quo leaves a dirty submodule repo on every build, which is not acceptable. Using VS for zlib and installing it system-wide is also not a solution for me. We need to build everything statically, with CMake, in one project, where the top-level project refers to zlib's CMakeLists.txt. A CMake option to disable renaming zconf.h (PR #519) seems to be something that could satisfy everyone's use cases in a backward-compatible way. |
|
I thought that cmake now includes nuget support as well, I guess another option would be for #732 to be merged (but changed to support use cases where not only .NET applications need to be able to use it but also native projects as well (C/C++). |
|
@madler: Can you look this @joeyparrish PR? Linked to: |
|
@joeyparrish @AraHaan already answered this. |
It has to be regenerated anyway, either through configure or CMake. Having it in the repo means that the CMake build will rename it, dirtying the repo when used as a submodule.
A simpler alternative to #519