[PATCH] D101139: Create install targets for scan-build-py.

[Yu Shan via Phabricator via cfe-commits]

aabbaabb added a comment.

In D101139#2718057 <https://reviews.llvm.org/D101139#2718057>, @phosek wrote:

> In D101139#2713530 <https://reviews.llvm.org/D101139#2713530>, @aabbaabb wrote:
>
>> The python script assumes relative directory while finding things. For example, for resources folder, it uses os.path.join(this_dir, 'resources') in report.py, which means resource need to be in the same dir as report.py. Similarly for the libscanbuild. it assumes the library is always at one level up from bin folder. Installing them to different directories would break the script.
>
> We could reorganize things to match the final layout, that's the strategy that https://github.com/llvm/llvm-project/tree/main/clang/tools/scan-build uses as well.
>
> In D101139#2713551 <https://reviews.llvm.org/D101139#2713551>, @aabbaabb wrote:
>
>> libear is built dynamically at runtime from build_libear function in libear/__init__.py which would be called by libscanbuild/analyze.py. It is not built statically.
>
> Could we modify the code to avoid building libear at runtime and instead build it with CMake. Is libear even needed when using compilation database?

If i copy libscanbuild/resources to out/share/, libscanbuild to out/libscanbuild, bin/* to bin, then resources would be in a different layout than the original src. You mean modifying the original source and move libscanbuild/resources out to share/resources and update the code reference?

We are not using libear, we are only using analyze-build not scan-build. For our usage, I could define a target that only copies analyze-build, not scan-build. However, I am not sure whether this is appropriate. On the other hand, building libear statically might require significant change to the code.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101139/new/

https://reviews.llvm.org/D101139