Package: scan-build
scan-buildA package designed to wrap a build so that all calls to gcc/clang are
intercepted and logged into acompilation databaseand/or piped to
the clang static analyzer. Includes intercept-build tool, which logs
the build, as well as scan-build tool, which logs the build and runs
the clang static analyzer on it.How to getIt’s available fromthe Python Package Index$ pip install scan-buildPortabilityShould be working on UNIX operating systems.It has been tested on FreeBSD, GNU/Linux, OS X and Windows.Prerequisitesclang compiler, to compile the sources and have the static analyzer.pythoninterpreter (version 3.6, 3.7, 3.8, 3.9).How to useTo run the Clang static analyzer against a project goes like this:$ scan-build <your build command>To generate a compilation database file goes like this:$ intercept-build <your build command>To run the Clang static analyzer against a project with compilation database
goes like this:$ analyze-buildUse--helpto know more about the commands.LimitationsGenerally speaking, theintercept-buildandanalyze-buildtools
together does the same job asscan-builddoes. So, you can expect the
same output from this line as simplescan-buildwould do:$ intercept-build <your build command> && analyze-buildThe major difference is how and when the analyzer is run. Thescan-buildtool has three distinct model to run the analyzer:Use compiler wrappers to make actions.
The compiler wrappers does run the real compiler and the analyzer.
This is the default behaviour, can be enforced with--override-compilerflag.Use special library to intercept compiler calls during the build process.
The analyzer run against each modules after the build finished.
Use--intercept-firstflag to get this model.Use compiler wrappers to intercept compiler calls during the build process.
The analyzer run against each modules after the build finished.
Use--intercept-firstand--override-compilerflags together to get
this model.The 1. and 3. are using compiler wrappers, which works only if the build
process respects theCCandCXXenvironment variables. (Some build
process can override these variable as command line parameter only. This case
you need to pass the compiler wrappers manually. eg.:intercept-build--override-compilermakeCC=intercept-ccCXX=intercept-c++allwhere the
original build command would have beenmake allonly.)The 1. runs the analyzer right after the real compilation. So, if the build
process removes removes intermediate modules (generated sources) the analyzer
output still kept.The 2. and 3. generate the compilation database first, and filters out those
modules which are not exists. So, it’s suitable for incremental analysis during
the development.The 2. mode is available only on FreeBSD, Linux and OSX. Where library preload
is available from the dynamic loader. Security extension/modes on different
operating systems might disable library preload. This case the build behaves
normally, but the result compilation database will be empty. (Notable examples
for enabled security modes are: SIP on OS X Captain and SELinux on Fedora,
RHEL and CentOS.) The program checks the security modes for SIP, and falls
back to 3. mode.intercept-buildcommand uses only the 2. and 3. mode to generate the
compilation database.analyze-builddoes only run the analyzer against the
captured compiler calls.Known problemsBecause it usesLD_PRELOADorDYLD_INSERT_LIBRARIESenvironment variables,
it does not append to it, but overrides it. So builds which are using these
variables might not work. (I don’t know any build tool which does that, but
please let me know if you do.)Problem reportsIf you find a bug in this documentation or elsewhere in the program or would
like to propose an improvement, please use the project’sissue tracker.
Please describing the bug and where you found it. If you have a suggestion
how to fix it, include that as well. Patches are also welcome.LicenseThe project is licensed under University of Illinois/NCSA Open Source License.
See LICENSE.TXT for details.