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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
