Sync to upstream #8
Conversation
* Fix Windows CI build. The Windows SDK versions present on our CI options (GitHub Actions hosted runners, AppVeyor) have headers that cause compilation warnings when included with MSVC operating in modern C modes (C11+). This PR disables the compilation warning caused by the Windows SDK headers, so we can get Windows feedback from CI. The warnings can be re-enabled when the Windows SDK used by our CI is upgraded to a version that doesn't trigger warnings. * Switch CI to GitHub Actions.
The Windows SDK versions present on our CI options (GitHub Actions hosted runners, AppVeyor) have headers that cause compilation warnings when included with MSVC operating in modern C modes (C11+). This PR disables the compilation warning caused by the Windows SDK headers, so we can get Windows feedback from CI. The warnings can be re-enabled when the Windows SDK used by our CI is upgraded to a version that doesn't trigger warnings.
There was a problem hiding this comment.
The CI + CMakeLists.txt as they stand here are not worth adding: https://github.com/willcl-ark/crc32c-subtree/actions/runs/10605521278/job/29394471127
But tests and benches can be relatively easily hacked(1) out(2) to get an array of simple build tests passing again: https://github.com/willcl-ark/crc32c-subtree/actions/runs/10605602819
(I assume this is preferable to merging 3rd party deps).
The rest is trivial enough.
| @@ -1,7 +1,6 @@ | |||
| # CRC32C | |||
|
|
|||
| [](https://travis-ci.org/google/crc32c) | |||
| [](https://ci.appveyor.com/project/pwnall/crc32c) | |||
| [](https://github.com/google/crc32c/actions/workflows/build.yml) | |||
There was a problem hiding this comment.
This isn't correct for us, but can be fixed later
|
The point is just to pull the upstream changes. Any other (relevant) changes could be done in a followup. |
|
Yes I agree, in this case it looks fine to me. 👍🏼 Ripping out the third party stuff from the CMakLists and CI is easy enough to do later. |
Pulls the few changes from upstream (last commit ~ 2 years ago).
Seems reasonable to do before making any other changes. i.e #7, or if we are going to make further changes to the CMake build system etc.