Updated CI, added CD

[mfep]

• Added .gitignore file,
• Added .clang-format (based on OpenCL-SDK's corresponding file) and format enforcing script.
• Minor changes to source files to avoid warnings on all compilers tested in CI.
  • -Werror//WX is enabled in CI
• Change to avoid adding . and .. dirs to ICD search paths when using layers.
• Refactored the CMakeLists.txt to be able to produce binary Debian packages using cpack.
  • CMake minimum version is bumped to 3.16.
  • Separate packages are generated for
    • the runtime component (similar in contents to package ocl-icd-libopencl1)
    • the dev component (similar in contents to package ocl-icd-opencl-dev)
    • and the cllayerinfo executable.
• Updated the CI (pre-release) script.
  • Removed the previous separate workflows for Windows, MacOS and Linux. All CI scripts reside in the presubmit workflow now.
  • Added a job that checks the changed code for formatting conformance via git-clang-format.
  • Updated Linux CI to use a new container image
    • Most jobs in the matrix are based on Ubuntu 22.04
    • Compilers gcc-11, gcc-13, clang-14, clang-16 and gcc-9 on Ubuntu 20.04
    • Binary targets: x86-64 and x86 on Ubuntu 20.04
    • CMake versions: 3.26 and 3.16 on Ubuntu 20.04
    • CMake generators: Ninja Multi-Config, Unix Makefiles
    • Added the generation of the Debian package and testing the consumption of the package
  • Updated Windows CI, which runs on Windows Server 2022
    • MSVC toolsets: v141, v142, v143, clang-cl (this latter with msbuild only)
    • Binary targets: x86-64, x86
    • CMake: system installed, currently 3.27
    • CMake generators: Ninja Multi-Config, Visual Studio 17 2022
    • Added the result checking of the external command invocations in the PowerShell snippets
  • Updated MacOS CI, which runs on MacOS 13
    • Compilers: Apple-Clang 14, gcc-11, gcc-13 (gcc with Ninja Multi-Config only)
    • Binary target: x86-64
    • CMake: system installed, currently 3.27
    • CMake generators: Ninja Multi-Config, XCode
    • Added test checking the consumption of the install tree
  • Added Android CI, which is build only (virtualization is not available with the default GitHub runners)
    • Binary targets: x86-64, arm64
    • Android API levels: 19, 33
• Added a release workflow which triggers on the push of a v* tag
  • Added DebSourcePkg.cmake which is intended to run in CMake script mode. This script generates the debian/control, debian/changelog and ``debian/rules` files which are required to build a Debian source package.
  • The release workflow generates the Debian source package and pushes it to a prescribed Launchpad PPA. The details of the release (e.g. maintainer, signing key) has to be set up as repository variables.
  • The generated source package builds 3 binary packages, similarly to the aforementioned CPack-based solution.
  • The generated package names are prefixed with khronos-opencl-loader, which is also the name of the source package that is generated. Thereby the 3 binary packages are named the following:
    • khronos-opencl-loader-libopencl1
    • khronos-opencl-loader-opencl-dev
    • khronos-opencl-loader-cllayerinfo
  • As an extra, and a difference from the ocl-icd-libopencl1, khronos-opencl-loader-libopencl1 does not conflict with other packages providing virtual package libopencl1. Instead it uses the update-alternatives program so that it can be co-installed with other packages providing libopencl1, given that those packages are also equipped with the update-alternatives integration. This update-alternatives integration is not present in the CPack generated binary package.
  • Detailed instruction regarding the release procedure is going to be added to the OpenCL SDK repository.

This PR is considered to be complete, albeit review remarks and/or changes to related PRs might warrant minor updates.

[CLAassistant]

All committers have signed the CLA.

[Kerilk]

Thanks for this contribution.

I don't know why the CI didn't trigger here. From what I understand it should have.

To get around the issue, I pushed the branch on my fork, but the CI failed:
https://github.com/Kerilk/OpenCL-ICD-Loader/actions/runs/7093978723/job/19308386439
So if we merge this we will most probably break the CI.

[mfep]

Thanks for this contribution.

I don't know why the CI didn't trigger here. From what I understand it should have.

To get around the issue, I pushed the branch on my fork, but the CI failed: https://github.com/Kerilk/OpenCL-ICD-Loader/actions/runs/7093978723/job/19308386439 So if we merge this we will most probably break the CI.

Hi, and thank you for looking at this.

I also don't know why the CI didn't trigger, but I wouldn't be too surprised if it was for security reasons. Since this PR changed the CI script, this would be a way to execute arbitrary code on the KhronosGroup CI cluster, if it existed.

The reason for the CI failure in your fork is due to the additions to the formatting checker script. The new formatting checker is incremental, i.e. only changes between the current commit and origin/main are considered. Since the default branch of your fork is named master, the script fails.

This job has run on the same commit as this PR's head, and was successful: https://github.com/StreamHPC/OpenCL-ICD-Loader/actions/runs/6339722153

[Beanavil]

Latest commits:

• update Docker images so that the ones from the khronosgroup Docker Hub are used

• fix MSVC compiler toolset version due to breaking change in the MSVC versioning (see cppblog)

  We have incremented the minor version number of the MSVC toolset from 19.39 (VS 2022 v17.9) to 19.40 (VS 2022 v17.10)

[bashbaug]

Merging as discussed in the June 18th teleconference.