Not able to build and run Utilities/ClangTidyModule

Development
1

After reading https://www.kitware.com/extending-clang-tidy-with-a-plugin-to-add-new-checks-for-cmake/
I tried to build Utilities/ClangTidyModule on OSX without success with various versions of Clang including the current HEAD of the LLVM project.

Beyond the obviously wrong CXX standard set for the project and some trivial namespace fix, I am getting link-time errors.

Is this something that is being actively tested/developed? What is the right way to use?

I can provide more information upon request but in short I configured with

cmake -S Utilities/ClangTidyModule -B Utilities/ClangTidyModule/build -DCMAKE_BUILD_TYPE=Debug -DRUN_TESTS=ON -DClang_ROOT=/path/to/llvm/project/install
2

It is being used in CI to perform the CMake-specific checks against CMake’s codebase. We’re using Fedora’s packages with some custom code to get an SDK (Fedora 38 should just have the fix).

Cc: @kyle.edwards

3

I was able to build using the Fedora 3.7 Docker setup you pointed at and the Clang 15.0.7 that comes with it.
I realize now the using C++17 is on the LLVM side (from version 16 onwards), not in Utilities/ClangTidyModule per se.
The namespace issue

cmake/Utilities/ClangTidyModule/UsePragmaOnceCheck.h:55:3: error: no type named 'FileExtensionsSet' in namespace 'clang::tidy::utils'; did you mean simply 'FileExtensionsSet'?
  utils::FileExtensionsSet HeaderFileExtensions;
  ^~~~~~~~~~~~~~~~~~~~~~~~

is with the latest LLVM (did not investigate when the changed occurred but 16.0.0 was fine).

I still don’t quite get the link-time error on OSX though :confused:

4

The clang-tidy module is tied to the version of LLVM (15.0.x) that’s present in the CI image. There is no expectation that it would work with any other version of LLVM. Whenever we update the CI image with a new version of LLVM, we will update the module to work with it.

5

Is there something special about the LLVM install that is in the CI image or do you expect that a 15.0.7 build of LLVM should in principle work?

6

In general it should work. When my team was initially developing the module we used a local debug build of LLVM that we had built from source outside of the container.