EwanC
commented
4 months ago Although I don't object to removing the clang-format CI at the moment, should we create an issue to decide whether we want to clang-format the headers at some point in the future? A solution where we add clang-format to the existing header generation script, or clang-format headers as a step in the CMake generate build target I think would integrate into a development flow more effectively than the current manual step we are disabling.
It's not completely analogous but examples of these two solutions are:
- Unified Runtime runs clang format as part of the generation script of
ur_api.h- https://github.com/oneapi-src/unified-runtime/blob/main/scripts/run.py#L179 - OCK runs clang-format as a CMake command when generating it's internal HAL API - https://github.com/codeplaysoftware/oneapi-construction-kit/blob/be5dd74a5328d6b7e57bdcb739d13567d442a986/modules/mux/tools/api/CMakeLists.txt#L86
We are removing the automated formatting checks before merging CI/CD changes in other repos, see for example: https://github.com/KhronosGroup/OpenCL-CLHPP/pull/262/commits/94eb4dfbd742afe0f36b29c9e562a2e479a0f784.
But, we've already merged the CI/CD changes for this repo, so this PR is needed to remove the automated formatting checks.
Removing the automated formatting checks is is helpful for this repo especially since it has a large amount of auto-generated code that is already formatted consistently.