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.
isthismyaccount on Apr 22 2021, 11:30 PM.Authored by
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.
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.
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.
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).
Updated the layout and listed individual files.
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.
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)
put libs in 'lib' folder, 'analyze-*' and 'scan-*' compiler wrappers to 'libexec', also copy the resources in 'libscanbuild'
Test at source folder:
One error in functional test: test_successful_build_on_empty_env
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.