search

llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
29.35k stars 12.14k forks source link

[clang][analyzer][build] Do not build the Static Analyzer for `ninja all` if disabled by `CLANG_ENABLE_STATIC_ANALYZER=OFF` #117705

Closed whisperity closed 3 days ago

whisperity commented 3 days ago

Currently, I am working on tasks for which building or having the Clang Static Analyzer is completely irrelevant professionally, but having to sit through CSA builds due to changes in code that causes CSA recompilations is a waste of time. I found the CMake options documented as toggleables (they show up in ccmake even without advanced options) CLANG_ENABLE_STATIC_ANALYZER, and turned it to OFF. I also had to OFF its dependency CLANG_ENABLE_ARCMT due to a scripted error message instructing me to do so.

Having done so, I can confirm that doing ninja clang does not build CSA-related things; that clang --analyze foo.cpp correctly reports the at-first little bit cryptic error: action RunAnalysis not compiled in. And indeed, lib/libclangStaticAnalyzerCheckers.a is not created. This is true for ninja clang when it is explicitly specified.

The other problem is that I often change tools which work best if the entire LLVM build directory is incrementally recompiled, as opposed to always needing to remember the most restrictive build target that actually achieves my current goal at that moment. For this, ninja — or ninja all in its full form — is a good command because the build system deals with the incrementality of the compilation. (Usually I do this because I have some other scripts that depend on having "most" of the usual contents of a full bin/ directory such as llvm-readelf, and it's simply much easier to do it this way than listing out all the "binutils" needed.)

But this is broken for CLANG_ENABLE_STATIC_ANALYZER=OFF! If in an incremental compilation scenario following a successful build of all top-level binaries I — perhaps accidentally — run ninja all, I get about 202 further build actions executed, and despite that clang --analyze ... still reports the inability to execute CSA, lib/libclangStaticAnalyzerCheckers.a is assembled and tools/clang/lib/StaticAnalyzer is populated with object files.

This is unexpected and unconventional. For example, we disable specific not important LLVM_TARGETS_TO_BUILD for development and deployment and doing ninja llvm does not cause the llc binary to be able to assemble for the disabled targets.

These two elements of the build directory take up 1.1 + 1.5 = 2.6 GiB of space, which is almost 10% of the total size of the build directory.

llvmbot commented 3 days ago

@llvm/issue-subscribers-clang-static-analyzer

Author: None (whisperity)

Currently, I am working on tasks for which building or having the Clang Static Analyzer is completely irrelevant professionally, but having to sit through CSA builds due to changes in code that causes CSA recompilations is a waste of time. I found the CMake options documented as toggleables (they show up in `ccmake` even without advanced options) `CLANG_ENABLE_STATIC_ANALYZER`, and turned it to `OFF`. I also had to `OFF` its dependency `CLANG_ENABLE_ARCMT` due to a scripted error message instructing me to do so. Having done so, I can confirm that doing `ninja clang` does **not** build CSA-related things; that `clang --analyze foo.cpp` correctly reports the at-first little bit cryptic `error: action RunAnalysis not compiled in`. And indeed, `lib/libclangStaticAnalyzerCheckers.a` is not created. This is true for `ninja clang` when it is explicitly specified. The other problem is that I often change tools which work best if the entire LLVM build directory is incrementally recompiled, as opposed to always needing to remember the most restrictive build target that actually achieves my current goal at that moment. For this, `ninja` — or `ninja all` in its full form — is a good command because the build system deals with the incrementality of the compilation. (Usually I do this because I have some other scripts that depend on having "most" of the usual contents of a full `bin/` directory such as `llvm-readelf`, and it's simply much easier to do it this way than listing out all the "binutils" needed.) **But this is broken for `CLANG_ENABLE_STATIC_ANALYZER=OFF`!** If in an incremental compilation scenario following a successful build of all top-level binaries I — perhaps accidentally — run `ninja all`, I get about 202 further build actions executed, and despite that `clang --analyze ...` still reports the inability to execute CSA, `lib/libclangStaticAnalyzerCheckers.a` is assembled and `tools/clang/lib/StaticAnalyzer` is populated with object files. These two elements of the build directory take up 1.1 + 1.5 = 2.6 GiB of space, which is almost 10% of the total size of the build directory.
llvmbot commented 3 days ago

@llvm/issue-subscribers-bug

Author: None (whisperity)

Currently, I am working on tasks for which building or having the Clang Static Analyzer is completely irrelevant professionally, but having to sit through CSA builds due to changes in code that causes CSA recompilations is a waste of time. I found the CMake options documented as toggleables (they show up in `ccmake` even without advanced options) `CLANG_ENABLE_STATIC_ANALYZER`, and turned it to `OFF`. I also had to `OFF` its dependency `CLANG_ENABLE_ARCMT` due to a scripted error message instructing me to do so. Having done so, I can confirm that doing `ninja clang` does **not** build CSA-related things; that `clang --analyze foo.cpp` correctly reports the at-first little bit cryptic `error: action RunAnalysis not compiled in`. And indeed, `lib/libclangStaticAnalyzerCheckers.a` is not created. This is true for `ninja clang` when it is explicitly specified. The other problem is that I often change tools which work best if the entire LLVM build directory is incrementally recompiled, as opposed to always needing to remember the most restrictive build target that actually achieves my current goal at that moment. For this, `ninja` — or `ninja all` in its full form — is a good command because the build system deals with the incrementality of the compilation. (Usually I do this because I have some other scripts that depend on having "most" of the usual contents of a full `bin/` directory such as `llvm-readelf`, and it's simply much easier to do it this way than listing out all the "binutils" needed.) **But this is broken for `CLANG_ENABLE_STATIC_ANALYZER=OFF`!** If in an incremental compilation scenario following a successful build of all top-level binaries I — perhaps accidentally — run `ninja all`, I get about 202 further build actions executed, and despite that `clang --analyze ...` still reports the inability to execute CSA, `lib/libclangStaticAnalyzerCheckers.a` is assembled and `tools/clang/lib/StaticAnalyzer` is populated with object files. These two elements of the build directory take up 1.1 + 1.5 = 2.6 GiB of space, which is almost 10% of the total size of the build directory.
tbaederr commented 3 days ago

This has been rejected in https://github.com/llvm/llvm-project/pull/71653 fwiw.

whisperity commented 3 days ago

This has been rejected in #71653 fwiw.

@tbaederr Then we should be revisit that issue. It's been almost a year and the comments in that patch do not apply and neither fixes nor removals had been made since. But I will continue the discussion there.