Create install targets for scan-build-py and include this target in fuchsia distribution.
Also move lib folder to match the distribution layout.
TESTED=local build. Verify scan-build could execute.
Paths
| Differential D101139
Create install targets for scan-build-py. AcceptedPublic Authored by isthismyaccount on Apr 22 2021, 11:30 PM.
Details
Diff Detail Event TimelineComment Actions I don't think this is sufficient. First, we want to be explicit and always list individual files to install, we don't use patterns. Second, since libscanbuild is a library, it shouldn't be installed inside the bin directory. I think those should go either into lib or share. libscanbuild/resources should definitely go into share as is already the case for scan-build. Third, libear is a native component so that one needs to be compiled first. Comment Actions 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.
Comment Actions
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. Comment Actions
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.
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? Comment Actions
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. Comment Actions
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 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). Comment Actions
Updated the layout and listed individual files. wanders added inline comments.
Comment Actions Rename scan-build to scan-build-py during install to prevent overwriting pearl implementation. Comment Actions Looking at libear/__init__.py, it's basically replicating CMake build to the point where it even emulates CMake template expansion, see https://github.com/llvm/llvm-project/blob/a3a8a1a15b524d91b5308db68e9d293b34cd88dd/clang/tools/scan-build-py/libear/__init__.py#L204. Given that we already use CMake, I think we should just build libear with CMake and ship libear as shared library and then modify https://github.com/llvm/llvm-project/blob/a3a8a1a15b524d91b5308db68e9d293b34cd88dd/clang/tools/scan-build-py/libscanbuild/intercept.py#L113 to use the prebuilt version instead of building it every time. However, given that this change is already pretty large, I'm also fine if we do it in a follow up change.
aabbaabb marked 3 inline comments as done. Comment ActionsRenamed lib to libexec and add custom rules to copy files to build output. aabbaabb marked 3 inline comments as done. Comment Actions
That rename was a bit too fast I think. (I have picked up this patch in our internal toolchain as it gives us a way to generate compilation databases out of the box. It works fine here) Comment Actions put libs in 'lib' folder, 'analyze-*' and 'scan-*' compiler wrappers to 'libexec', also copy the resources in 'libscanbuild' Tests: To install: Test at source folder: One error in functional test: test_successful_build_on_empty_env Comment Actions I think this looks good. I can't vouch for the cmake changes. However there seems like diff is based on something that already has moved parts into libexec. It doesn't apply cleanly here - and buildkite seems to complain too. Make sure you have the complete diff. This revision is now accepted and ready to land.Jun 9 2021, 10:37 AM Comment Actions Thanks for the reviews. I'll take over this and try to get the merge conflicts resolved.
Revision Contents
Diff 351308 clang/cmake/caches/Fuchsia-stage2.cmake
clang/tools/CMakeLists.txt
clang/tools/scan-build-py/CMakeLists.txt
clang/tools/scan-build-py/bin/analyze-build
clang/tools/scan-build-py/bin/analyze-c++
clang/tools/scan-build-py/bin/analyze-cc
clang/tools/scan-build-py/bin/intercept-build
clang/tools/scan-build-py/bin/intercept-c++
clang/tools/scan-build-py/bin/intercept-cc
clang/tools/scan-build-py/bin/scan-build
clang/tools/scan-build-py/lib/libear/__init__.py
clang/tools/scan-build-py/lib/libear/config.h.in
clang/tools/scan-build-py/lib/libear/ear.c
clang/tools/scan-build-py/lib/libscanbuild/__init__.py
clang/tools/scan-build-py/lib/libscanbuild/analyze.py
clang/tools/scan-build-py/lib/libscanbuild/arguments.py
clang/tools/scan-build-py/lib/libscanbuild/clang.py
clang/tools/scan-build-py/lib/libscanbuild/compilation.py
clang/tools/scan-build-py/lib/libscanbuild/intercept.py
clang/tools/scan-build-py/lib/libscanbuild/report.py
clang/tools/scan-build-py/lib/libscanbuild/resources/scanview.css
clang/tools/scan-build-py/lib/libscanbuild/resources/selectable.js
clang/tools/scan-build-py/lib/libscanbuild/resources/sorttable.js
clang/tools/scan-build-py/lib/libscanbuild/shell.py
clang/tools/scan-build-py/libear/__init__.py
clang/tools/scan-build-py/libear/config.h.in
clang/tools/scan-build-py/libear/ear.c
clang/tools/scan-build-py/libexec/analyze-c++
clang/tools/scan-build-py/libexec/analyze-cc
clang/tools/scan-build-py/libexec/intercept-c++
clang/tools/scan-build-py/libexec/intercept-cc
clang/tools/scan-build-py/libscanbuild/__init__.py
clang/tools/scan-build-py/libscanbuild/analyze.py
clang/tools/scan-build-py/libscanbuild/arguments.py
clang/tools/scan-build-py/libscanbuild/clang.py
clang/tools/scan-build-py/libscanbuild/compilation.py
clang/tools/scan-build-py/libscanbuild/intercept.py
clang/tools/scan-build-py/libscanbuild/report.py
clang/tools/scan-build-py/libscanbuild/resources/scanview.css
clang/tools/scan-build-py/libscanbuild/resources/selectable.js
clang/tools/scan-build-py/libscanbuild/resources/sorttable.js
clang/tools/scan-build-py/libscanbuild/shell.py
clang/tools/scan-build-py/tests/__init__.py
clang/tools/scan-build-py/tests/functional/cases/__init__.py
clang/tools/scan-build-py/tests/functional/cases/test_exec_anatomy.py
clang/tools/scan-build-py/tests/functional/cases/test_from_cdb.py
clang/tools/scan-build-py/tests/functional/cases/test_from_cmd.py
clang/tools/scan-build-py/tests/unit/test_analyze.py
|
I'd prefer to install all of these into libexec to match Perl scan-build.