forked from madler/zlib
-
Notifications
You must be signed in to change notification settings - Fork 0
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 now produces output identical to configure/make, and CI verifies this. #6
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To make it easier to accept contributions to zlib we should establish automated testing. This commit uses the existing test/example.c testing. It connects those tests to AppVeyor, allowing AppVeyor to mark commits as passing or failing the tests. It also automatically runs tests when a pull request is submitted or updated. There is some room for future expansion enabled, such as tracking the file and line of a failing test. This is thanks to @dankegel, who also got this working on CI providers other than AppVeyor.
… additional options
… on, otherwise no change.
…rrus/github - pass file and line the way cirrus' junit parser expects - pass executable name as 'classname' in junit output so executable name shows up in github annotations - don't output file or line on success, since annotating those on github just adds clutter
CMakeLists.txt: output junit result file for each test executable to ${CMAKE_CURRENT_BINARY_DIRECTORY}. (Would have liked to output them to the $<CONFIG> subdir on Windows for multi-config generators like Visual Studio, but alas, I couldn't coax cmake's generator expressions into working portably without complicating CMakeLists.txt beyond reason. Happily, it's uncommon to run both Release and Debug build and test in same tree on CI builders.)
…#497 - default build type to Release - set -DHIDDEN properly - pass .c files to compiler in same order - on linux/bsd, link libz.so with -lc explicitly (as Makefile.in does, but why?) - output same libz.pc and zconf.h as Make
dankegel
force-pushed
the
issue497-identical-builds
branch
3 times, most recently
from
May 25, 2020 03:22
21e6e59
to
ec4b989
Compare
…and madler#499 Run cmake first and configure/make second, see issue madler#499 (build breaks due to zconf.h missing) ci: add fedora, debian; use matrix and a template in .cirrus.yml
dankegel
force-pushed
the
issue497-identical-builds
branch
from
May 26, 2020 02:33
5670645
to
18f9f4d
Compare
dankegel
force-pushed
the
develop
branch
2 times, most recently
from
May 26, 2020 21:53
b9ee2d6
to
0af1b78
Compare
Closing in favor of madler#500 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes madler#497, at least on Linux, Mac, and FreeBSD.
Also: don't let Make build accidentally include a stale zconf.h. (So also fixes madler#499.)