-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
cmake-remake #1027
base: develop
Are you sure you want to change the base?
cmake-remake #1027
Conversation
superseeds madler#265 and madler#170 and part of madler#148
add option to also install zlib1.ddl for compat partially superseeds madler#976
adjust min required version for regex, superseeds madler#43
…by check_type_size anyways superseeds madler#432
…t_compile_definitions
…tter informations all over the place
9599519
to
4d59e1a
Compare
@Vollstrecker I'm seeing lots of passed checks now. Do you think this is ready for prime time? |
I reworked the minizip tests as they were basically copied from zlib as boilerplate and then forgotten (not yet pushed) and am currently working on the components split. Hopefully I'll get this done in the next hours, Then only a little readme is missing. I've put this PR public when I was ready to also react on critics and wishes, but it seems all others are basically fine so far. |
0c83ea3
to
91c8f61
Compare
91c8f61
to
982f03e
Compare
I guess I'm done - with some confusion First: the thing with minizip and bzip2, I would have expected to get some errors about missing symbols from the compiler when HAVE_BZIP2 is set, but it seems none of the tests is using this and I don't get any errors when not linking against it. Should a hard dependency on bzip2 be added anyways, or should it stay like described in the README? Second: The cygwin workflow almost always fails at the first run but succeeds when restarted. As it fails on different places during the compile stage I suppose some random segfault on cygwins side. Should this test be disabled until someone that knows the system better can fix this? |
For all with an opinion on this topic, cmake 3.10 as minimum is old I know that, but I don't miss any feature of newer versions that are needed. If you really need anything for newer versions that doesn't work in this one, now is the time to complain. The question in this case is just what should be supported. If Ubuntu LTS 20.04 is still a thing, 3.16 would be possible. If Ubuntu LTS 22.04 is the magic boundary, we could jump to 3.22. Newer than 3.25 I wouldn't like to go as then at least Debian stable will still work. And yes, as the workflows get newer version and every time this happens an older version will be deprecated, this minimum will increase over time and newer methods will then also be included for the new minimum when applicable. |
@Vollstrecker One check failed. (mingw/cygwin / Cygwin) |
Yes, I mentioned that as the second point. Mostly if fails on the first and succreds when restartet. I asked if I should leave it in as it seems something like a segfault happens. |
Forgot to mention: While minizip compiles fine on mingw32 which reports 32Bit integers, I wasn't able to get the same with -m32 on gcc. Maybe someone can take a look on that also. |
Hi,
I guess I have everything together. A quick overview:
The tests on dll based plattforms are mostly run with only the static libs as dll has no rpath option. I also aded a runner file for cygwin and msys. cygwin succedes after restarting the job, but not on the first one, so I renamed the file. I can't reproduced that locally even when using the commands from the runner. Maybe someone with more knowledge in these systems and/or yml can improve this part.
For minizip there are currently no tests run as the would need codechanges that are not subjected here. There are c++-style comments that aren't allowed here and warnings ab out data loss when converting _uint64 to long here. Also I wasn't able to find the right symbol to export the api and had to tell windows to export them all. Maybe someone has more insight here also.
Some questions are still open:
#116 also set's ZLIB_WINAPI, when is this needed?
#72 adds contrib/masmx64/inffas8664.c, if so, when should this be added?
#539 How often will it happen to have semicolon in you dir names?
So I guess these 3 could be closed later by hand.
For #983 I can't say anything as I've never crosscompiled, maybe @trcrsired can check on that
So here's the list of stuff that's done:
Closes: #43 #132 #133 #138 #148 #162 #170 #177 #218 #219 #265 #271 #277 #315 #337 #344 #359 #366 #432 #444 #471 #472 #489 #526 #543 #545 #558 #581 #713 #718 #721 #762 #781 #816 #818 #831 #835 #849 #899 #966 #976 #1009 #1026
In addition there are some that are fixed but not closed before:
Closes: #242 was closed can be closed again
Closes: #259 because it's possible with cmake
Closes: #270 vc15 not needed anymore
Closes: #306 because Makefile.msc is gone already
Closes: #428 symbol is not found anywhere
Closes: #575 was fixed before
Closes: #569 because Makefile.msc is gone already
Closes: #600 duplicate of #162
Closes: #652 because there was a merged fix
Closes: #860 done but not closed
Closes: #972 seems to be a usage error
For the future I also plan cpack integration for neat creation of installers, and to look at everything that's not included (examples/contrib). If there occur any problems I could offer you to open the issue-tracker on the cmake-remake fork to keep track there (not my first choice as users would need to know) or that you highlight me or the project (no clue if this is possible) to support the future of zlib from that side.