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

[Yu Shan via Phabricator via cfe-commits]

aabbaabb added a comment.

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

> In D101139#2718112 <https://reviews.llvm.org/D101139#2718112>, @aabbaabb wrote:
>
>> 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?
>
> Do we still keep the source in sync with https://github.com/rizsotto/scan-build? I was under the impression that the two codebases have already started diverging.
>
>> 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.
>
> We may consider introducing a CMake option to control whether to include libear or not (which would also control whether to include `scan-build` or not).

Updated the layout and listed individual files.
It is not trivial to separate out scan-build with analyze-build since all the logic is in one python lib file. Furthermore, libear is compiled with the cc compiler that is supplied as an argument to the tool, so i cannot turn that into a prebuilt without a large refactor to the codebase. I added a comment listing the reason.


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

https://reviews.llvm.org/D101139