A way of specifying which Clang/clang-tidy to use

[tinloaf]

Hi,

I have mulitple Clang versions installed on my system (via the LLVM APT repository), so I want CodeChecker to use the binary /usr/bin/clang++-17 on my system.

The only way I could find to achieve this was to manually edit the package_layout.json file bundled with CodeChecker. This is problematic because this file might be overwritten again with the next update. I figured from the code that it should be possible to copy the whole ~/.local/share/codechecker directory somewhere, edit the package_layout.json file contained therein, and then set the CC_DATA_FILES_DIR environment variable accordingly. This would mean that future updates do not overwrite my custom package_layout.json file, but also that all other files in the data directory will not automatically be updated.

Is there a more elegant way of specifying the Clang executable to be used?

[bruntib]

Hi,

There is an environment variable CC_ANALYZERS_FROM_PATH (its value can be yes, or 1) that forces the usage of clang from the PATH. This might be a little more elegant solution. It is among our plans to tidy this part up in the future.

[tinloaf]

Thanks.

Would this be something you would accept a PR for? If so, which direction of cleanup did you have in mind? My first instinct would be to add further environment variables that allow overriding the clangsa, clang-tidy and cppcheck values from package_config.json, e.g. a variable CC_CLANGSA_EXE=/path/to/clang. But that would not really be a cleanup but "adding more parameters".

[bruntib]

In the long terms we plan a plugin interface for CodeChecker so adding a new analyzer can be done easily. The mechanism of finding the proper analyzer binary would be a part of it. However, it would be useful to collect ideas about how users could do the configuration. The current package_layout.json is quite limited, because sometimes users don't even have access to a read-only drive where CodeChecker is installed. Traditionally the config options are 1. environment variable, 2. config file in a local "home" or some other folder, and 3. command line argument (not necessarily in this order and not necessarily all of them).