Fix Visual Studio 2022 projects (create zconf.h) #1039
Conversation
Corrections in the related readme.txt
|
You're sure you want to keep all these projects? With the working cmake I would consider this all deprecated. |
For those who still use ed for writing code, |
I would indeed like to deep six all of the VS projects if cmake is a viable alternative. Does VS come with cmake? Or does it need to be separately installed? Does or can cmake generate a VS project? |
|
yes to both 👍 Does VS come with cmake? can cmake generate a VS project? |
|
Ok, then @irwir , why should I not delete the VS projects, if they can be generated using cmake? |
Very brave statement.
This library has vc9 (2008) to vc17 (2022) configurations. Would you kindly provide a similar quote for VS2012 or earlier? Even in VS2022 CMake is optional, as clearly written on the screenshot; neither IDE nor compiler depend on it. It safely could be unchecked and thus not installed (if user knows what and why he is doing).
https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2012%202013.html Dear CMake fanboys! Please use Discussions instead of hijacking every topic related to VS projects. |
For the same reasons why many repositories provide VS projects, maybe? Alternatively, why you just do not return |
I would like to do that. Though it is my understanding that that would screw up cmake. Is there a way to restore zconf.h in the distribution that is compatible with cmake? |
I can't quite parse that. Can you elaborate on your proposal? |
|
Bringing zconf.h back from cmake POV is not that big problem. If in doubt it could go into a subdir that get's included in VS-projects and is ignored everywhere else. Setting ZPREFIX would mean to edit a file which could be avoided, but everything else is doable if stuff like unistd.h can be assumed to be always there. The important question is: How old is a Visual Studio that's not supported by cmake? A recent version of VS is free for private and open source usage on recent versions of Win. So why support WinXP instead of just telling people to upgrade their systems that are not only unsupported by cmake, they are unsupported by MS and shouldn't be used at all anymore. Like it or not, it's just like it is. And yes devs of commercial software need to pay for newer VS, but that's no excuse to keep dead plattforms alive. |
|
Maybe it can be separated in several repositories? |
This is a case for CMake gurus to shine; there should be a way.
As an example: a repository has no .vcxproj files; but it has project generator scripts instead.
People habitually try to teach other how to live. |
I would like to bring back zconf.h to the base directory, independent of whether there are or are not VS projects. Can that be done? |
|
Fir bringing it back, I guess configure also needs adjustments. Suggestion: A Branch where you put zconf.h in place with reasonable defaults and adjusted configure and I adjust to cmake to overwrite the defaults that don't fit. I'm home tomorrow and the day after, should be plenty of time.
I just asked but I guess youi say "I could tell you a good reason but actually it's a dumb one so I answer that way". |
Possibly a silly question. |
|
It could, if there would be an issue. By now cmake parses zconf.h.in and adds the needed stuff to generate zconf.h, so I don't really care what file to parse, the only thing needed is to make sure that the generated one (or better it's path) appears before the other one in the compile command, and that include statements in the code respect that. Removing the file would pollute the git tree, the whole cmake-part is designed for complete out-of-tree builds. There's nothing more annoying than have changed file in git just because you've built the source. |
|
Until very recently, zconf.h never needed "generation", it was static; VS and make would nicely build the library. |
|
Parsing is done basically to set Z_PREFIX from configure or cmake options. Plus there are checks for stadrg.h and unistd.h presence that need to be set in zconf.h as HAVE_STDARG_H and HAVE_UNISTD_H. I guess these checks are there for a reason. I didn't check all the code, if they are needed and missing them would break everything, we could remove the checks for them in the code completely and let configure and cmake fail if they are not found, if they are really optional there's no real option other than either generating this file, or removing the statements and give the flags as compiler switch. |
|
The This PR looks incomplete to me: it only adjusts the VS2022 project file. Or, are all the other VS project files correct and that's why they haven't been adjusted? And to add my twopence: I'd get rid of the VS files from here because they're redundant and easily out-of-date due to maintenance issues. Cmake can generate native project files for VS 2008-2022 plus nmake projects, which are more likely to be correct and without the maintenance overhead. It can also generate Xcode projects and other project types too for both IDEs and command line builds. I'd suggest getting rid the Makefiles and configure script and just leave CMake, but I'm sure Mark will point out some esoteric platform with no CMake binaries is in use somewhere ;). |
There is a zconf.h.in from which configure writes zconf.h. That's always been the case, and still is in the current develop branch. So for configure and make, there does not need to be a zconf.h. The change in the current develop branch is now zconf.h is gone. I would like for zconf.h to return to the top directory of the distribution, so that it is possible to compile zlib without make or cmake or bazel or vstudio or xcode or anything. Just compile all the source files in the top directory and link them. Done.
I would like to understand this pollution better. Why can't a zconf.h in the top directory co-exist with cmake? |
Maintenance is the reason I would like to remove all of the VS project files from the distribution. Can someone provide instructions for generating them using cmake, so I that I can include that in the distribution in lieu of the project files? |
If making process changes contents of zconf.h, git would try to push this file.
It would be nice to keep the projects in the distibution. |
Just into a clean checkout of the repo and run configure followed by git status, there are changed and unversioned files. If you're using an IDE these also get listed in the part for git and you always need to be carefull to not commit them with your changes.
Just run cmake -h and you'll get list of available generators for you current system. Choose one and append -G "" to your cmake call. You can the this in the actions. If you use cmake-gui and press configure for the first time, you'll get a dropdown-list with the available one and choose from there. I just checked, on my Win10 with VS17 I get offered VS9 to 17, except 13. All are list with year: Visual Studio 9 (2008) and all are 2 years apart, so I guess 13 never made it to the public. So with this everything in the contrib/VS-dir seems covered. And yes, I didn't check if you get cmake-binaries for a system designed in 2008 but I'm pretty sure if anyone wants to compile zlib there it's not to much to compile cmake there. |
I am thinking of someone getting the distribution and only using cmake, never configure and make. What if zconf.h is there, but you have not and will not run configure? Is there any issue? |
|
Just for fun I created zconf.h with just #error in it. No problem here. |
|
A bit too fast, as I was in the wrong dir. I also needed to change #include "zconf.h" to #include <zconf.h> in zlib.h to make it work. |
Strange. Standards pdf tells, if "..." form fails, it is repeated in <...> form. |
I'm not sure exactly what you made work with what when changing what, but anyway, are you saying that having a zconf.h in the top directory is not a problem? |
|
Not a problem.
Would be new to me. They are defined with different behaviour and if it's there by intent there can be various problems if that is altered. Is this a compiler pdf or some optional feature to turn on? |
C language standards; therefore - any conforming compiler. This behaviour is from C11; C90 made no such distinction. @madler |
|
@Vollstrecker Well, I tried putting zconf.h back, and now there are failures in the workflows. E.g. https://github.com/madler/zlib/actions/runs/13169400570 |
Fixes: madler#1039
Fixes: madler#1039
This PR would not be merged "as is". As for CMake, it can do well with zconf.h in distirbution. |
|
A comment about the VS readme.txt file: the link on this line is dead, even if I change it to HTTPS. |
|
@Vollstrecker I tried your change to use zconf.h instead of zconf.h.in for cmake, but the actions still result in lots of errors. |
|
Seen that, investigating that, running out of time for this week. On my system mostly the find_package tests fail, but I guess I missed some cornercase somewhere else. |
Thanks! No rush. |
This is a minimalistic fix for Visual Studio 2022 only.
Successfully builds for all Intel configurations.
It could be enhanced - for example, .filters files added to make project trees look better in IDE.
Please see if anything needs to be changed.
Additional remarks - separate issues might be created.
ReleaseWithoutAsmconfiguration; currently there is no single *.asm file in the source code.zconf.h). But, this is rare, and usually only the library project would be needed, not the provided solution.