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/ _______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
