[PATCH] Add scan-build python implementation

[Laszlo Nagy]

In http://reviews.llvm.org/D9600#190421, @dcoughlin wrote:

> Thanks for the update! Some additional questions:
>
> - Why does scan-build-py need to distinguish between "installed" and "non-installed mode"? And, in particular, does using the dynamic linker preload technique require installation? It seems to me that it shouldn't.


yes, currently the preload technique require installation. i can change that and do the compilation on the fly, so does not require installation. although i don't really understand the hesitation against installed packages. (more people are using installed Clang than who works from the source tree.)

> - Can we just remove "installed mode"? What benefit does it provide? If the only benefit is speed, do you think the speed is worth the extra complexity?


i would rather keep the preload technique, because:

- it has far better coverage on build systems. users does need zero modification on build scripts in order to run the analyzer. (not to mention the fact that open projects page <http://clang-analyzer.llvm.org/open_projects.html> mention it as a goal to achieve.)
- it generates a compilation database. it might be not a big deal for you guys in the static analyzer world, but it seems there is a demand among the users of tooling. wouldn't be nice to have such tool inside the Clang repo?

> - Does your latest update call the existing perl ccc-analyzer script? I see you have added python-based "intercept-cc" and "intercept-cxx". Can scan-build-py be changed to call the existing ccc-analyzer rather than doing its own wrapping? The goal of deferring to ccc-analyzer is to make sure that we preserve the existing behavior of scan-build.


short answer is: no, it does not.

long answer is: on 6/23/14 i submitted a patch which was a rewrite only the `ccc-analyzer` script. it was in mind to do the upgrade step-by-step. that time it was not attractive for you guys and wanted a full replacement. and was also recommended by not follow the Perl implementation too closely.

i don't think the goal of deferring to `ccc-analyzer` is a good acceptance criteria. i did this check in the past to make sure the rewrite does the same thing. but then went further ahead and changed the architecture.


http://reviews.llvm.org/D9600

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/