# Not able to build and run Utilities/ClangTidyModule
**URL:** https://discourse.cmake.org/t/not-able-to-build-and-run-utilities-clangtidymodule/7995
**Category:** Development
**Created:** [April 26, 2023, 10:25pm UTC](https://discourse.cmake.org/t/not-able-to-build-and-run-utilities-clangtidymodule/7995 "2023-04-26T22:25:02Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@dalg24](https://discourse.cmake.org/u/dalg24)
#### Post date: [April 26, 2023, 10:25pm UTC](https://discourse.cmake.org/t/not-able-to-build-and-run-utilities-clangtidymodule/7995/1 "2023-04-26T22:25:02Z")
After reading [https://www.kitware.com/extending-clang-tidy-with-a-plugin-to-add-new-checks-for-cmake/](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
```auto
cmake -S Utilities/ClangTidyModule -B Utilities/ClangTidyModule/build -DCMAKE_BUILD_TYPE=Debug -DRUN_TESTS=ON -DClang_ROOT=/path/to/llvm/project/install
```
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [April 26, 2023, 11:02pm UTC](https://discourse.cmake.org/t/not-able-to-build-and-run-utilities-clangtidymodule/7995/2 "2023-04-26T23:02:07Z")
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](https://gitlab.kitware.com/cmake/cmake/-/blob/master/.gitlab/ci/docker/fedora37/install_clang_tidy_headers.sh) to get an SDK (Fedora 38 should just have the fix).
Cc: @kyle.edwards
---
### Author:  [@dalg24](https://discourse.cmake.org/u/dalg24)
#### Post date: [April 27, 2023, 1:10pm UTC](https://discourse.cmake.org/t/not-able-to-build-and-run-utilities-clangtidymodule/7995/3 "2023-04-27T13:10:38Z")
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
```auto
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 😕
---
### Author:  [@kyle.edwards](https://discourse.cmake.org/u/kyle.edwards)
#### Post date: [April 27, 2023, 1:41pm UTC](https://discourse.cmake.org/t/not-able-to-build-and-run-utilities-clangtidymodule/7995/4 "2023-04-27T13:41:32Z")
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.
---
### Author:  [@dalg24](https://discourse.cmake.org/u/dalg24)
#### Post date: [April 27, 2023, 3:27pm UTC](https://discourse.cmake.org/t/not-able-to-build-and-run-utilities-clangtidymodule/7995/5 "2023-04-27T15:27:07Z")
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?
---
### Author:  [@kyle.edwards](https://discourse.cmake.org/u/kyle.edwards)
#### Post date: [April 27, 2023, 3:46pm UTC](https://discourse.cmake.org/t/not-able-to-build-and-run-utilities-clangtidymodule/7995/6 "2023-04-27T15:46:37Z")
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.