Closed igrr closed 12 months ago
This might also allow us to remove GCC_FLAGS_MAPPING
related logic.
Currently the clang version used is one installed via idf_tools.py install xtensa-clang
however we would like to use the latest version available at https://github.com/espressif/llvm-project/releases/tag/esp-14.0.0-20220415. Is there a way to specify the clang location. Would this issue resolve this too ?
@AshUK You can simply download and extract the latest LLVM version somewhere, then add the bin
subdirectory of the PATH ahead of other paths. You can check it by running which clang
— this should return the path to the location where you have extracted the latest LLVM version.
We will update LLVM version in idf_tools.py after the upcoming LLVM 15 based release.
This issue is not related to choosing the particular location of clang to use; it is just about letting the IDF build system know that the compiler is 'clang' — which prevents adding GCC-specific flags, among other things.
This has been resolved in https://github.com/espressif/esp-idf/commit/0349f471af27aea234544e2cf3152d8d31bef66d. The need of IDF_TOOLCHAIN=clang
is now mentioned in the docs.
Closing this issue!
Normally when we run
idf.py reconfigure
, that uses the GCC based toolchain. IDF build system adds various command line options specific to GCC, and clang doesn't recognize them. This results in unknown argument warnings reported by clang-tidy.Since IDF 5.0, there is initial support for compiling ESP-IDF with clang based toolchain. It is activated by setting
IDF_TOOLCHAIN=clang
in the environment or in CMake cache, before configuring the project.IDF_TOOLCHAIN=clang idf.py clang-tidy-check
behaves better and doesn't report the unknown argument warnings.Not sure if this is something we should fix in the idf.py action extension or simply mention this in the docs. Leaving this as an open issue for now.