KhronosGroup
Add Travis + AppVeyor CI
Though #62 and #63 are up for review already, I'd also like to submit my take on adding CI to the ICD loader, since this is in use successfully over at bincrafters/conan-khronos-opencl-icd-loader already for generating ICD binary artifacts.
This matrix uses the Conan Package Tools to build significantly more configurations:
- Architectures: x86, x86_64, armv7hf, armv8
- Operating Systems: Linux, Windows, macOS (MinGW requires patches, that's why I haven't added it to this matrix)
- Compilers:
- gcc 4.9 to 8 (I'll add 9 once there's a Docker image available)
- clang 3.9 to 8
- Apple Clang 8.1 to 10.0
- VS 2013 to 2017 (2019 will be added once AppVeyor supports it)
- Build Configuration: Debug, Release (on Windows with the different runtimes set)
- Library Type: Static, Shared
Since almost all permutations of above matrix are built, this sums up to >150 builds and should give us a very nice coverage.
RFC
- Should we keep macOS builds? We all know Apple's stance on OpenCL, sadly. It builds just fine at the moment, but the question is whether we should continue to test for it.
- Inside of the conanfile I download the OpenCL Headers from master. I'm not exactly a fan of this, as changes on the headers may manifest in failed CI on unrelated changes on the ICD, resulting in unnecessary blockages.
- We have an OpenCL Header package on Conan which we could use
- Alternatively we could pin the commit hash and update it manually from time to time
Random thought: We can put the manual testing setup in the conanfile.py so we have it on CI.
However, I'd like it to be done properly later on (maybe chroot on Unix and Registry Virtualization on WIndows?)
I have merged #62 and #63, because they were quick to review. This PR can be viewed as a change on top of those.
Regarding your RFC points:
- I see no reason to not test MacOS, especially as it is currently working.
- Although in theory changes to OpenCL headers on the master branch could temporarily cause breakage here in reality (a) header changes hopefully rarely break existing code as they are widely used, and (b) if master branch of the OpenCL ICD won't build with the master branch of the OpenCL headers that would need to be fixed anyway.
