Hi all,
I'm thinking of the following improvements to scan-build and want to discuss them with the community and to hear your thoughts and opinions:
First of all, refactoring: keep all scan-build arguments in the hash rather then in scattered variables.
This will make the scan-build code easier to understand and make it easier to re-engineer the code in the future.
Then I intend to add a possibility for scan-build to read options from a simple INI-like (INI file - Wikipedia) configuration file.
Values (if any) from this file will override default hardcoded values but do not override those obtained from the command line.
The file may have separate sections for scan-build, ccc/c++-analyzer and environment variables (if needed).
This will concentrate all the analyzer settings in the single place and will allow users to easily observe the default values all-together and to customize scan-build invocations of their own will.
I also intend to add several additional options to scan-build:
1) Set of additional flags for ccc/c++-analyzer (e.g. additional include paths, defines, optimization options, e.t.c).
Often after 'configure' analysys with Clang ended up with different errors and I had to manually patch makefiles to transfer additional flags to Clang to make it work. It was a real headache.
Here is random example of how this additional flags looked like: '-g0 -Os -fpermissive -D__STRICT_ANSI__ -I "F:/---OGRE/ogre_src_v1-8-1/include" -I "F:/---OGRE/ogre_src_v1-8-1/OgreMain/include"'...
So many times I wished to put extra flags somewhere so that ccc/c++-analyzer could take them and pass to Clang!
In configuration file it might look like the following:
CLANG_EXTRA_CXXFLAGS = -g0 -Os -fpermissive -D__STRICT_ANSI__ -I "F:/---OGRE/ogre_src_v1-8-1/include" -I "F:/---OGRE/ogre_src_v1-8-1/OgreMain/include"
2) If it happens so that both gcc and Clang are used after configuration then they share the same set of flags and the problem increases - Clang do not recognize some of gcc flags.
So I wish to add another option to scan-build, (e.g. CLANG_EXCLUDE_CXXFLAGS in config file) that will hold flags to be excluded from Clang invocation.
3) The third option is to add a possibility to completely bypass compilation step by gcc(g++, etc.) - this partially solves problems with options and, what is more important, may significantly reduce overall analisys time.
May I move forward with this?
Any thoughts and suggestions are welcome!
Better documentation of the flags that scan-build is going to pass to clang would be top of my list. I don't want to tie running the static analyser to a build step, I want my build system to generate an analyse target.
David
hi Anton,
hi David,
i was working on to re-implement scan-build functionality in python. (the result you can find <https://github.com/rizsotto/Beye>) currently i am struggling with python packaging. (but it’s already works on Linux and FreeBSD.)
and it works as you desired. 
it has two major parts: one which capture the compiler invocations and log those into a compilation database. and the one which run the static analyzer against the compilation database and generate the report. (in between the two you might run a program which transforms/filters command line arguments, if that desired.)
regards,
Laszlo
Great! Do you plan to support Windows?
i do not have access to windows machine, so i can’t do it by myself.
Ping!
Jordan, Anna, Ted, I'd love to hear your opinion. Do you think it make sense to move forward with it?
Hi all,
I’m thinking of the following improvements to scan-build and want to discuss them with the community and to hear your thoughts and opinions:
First of all, refactoring: keep all scan-build arguments in the hash rather then in scattered variables.
This will make the scan-build code easier to understand and make it easier to re-engineer the code in the future.
I’m not convinced of this. Either you have scattered options globally, or you have options in one place looked up by scattered string keys. I’d honestly prefer the globals because they’ll let me know if I have a typo.
Then I intend to add a possibility for scan-build to read options from a simple INI-like (http://en.wikipedia.org/wiki/INI_file) configuration file.
Values (if any) from this file will override default hardcoded values but do not override those obtained from the command line.
The file may have separate sections for scan-build, ccc/c+±analyzer and environment variables (if needed).
This will concentrate all the analyzer settings in the single place and will allow users to easily observe the default values all-together and to customize scan-build invocations of their own will.
This seems reasonable. At the very least recording specific checkers to turn on or off makes sense. On the other hand, if it’s just things that can be controlled on the command line, does it really offer that much more flexibility than someone writing their own wrapper scan.sh / scan.bat?
I also intend to add several additional options to scan-build:
- Set of additional flags for ccc/c+±analyzer (e.g. additional include paths, defines, optimization options, e.t.c).
Often after ‘configure’ analysys with Clang ended up with different errors and I had to manually patch makefiles to transfer additional flags to Clang to make it work. It was a real headache.
Here is random example of how this additional flags looked like: ‘-g0 -Os -fpermissive -D__STRICT_ANSI__ -I “F:/—OGRE/ogre_src_v1-8-1/include” -I “F:/—OGRE/ogre_src_v1-8-1/OgreMain/include”’…
So many times I wished to put extra flags somewhere so that ccc/c+±analyzer could take them and pass to Clang!
In configuration file it might look like the following:
CLANG_EXTRA_CXXFLAGS = -g0 -Os -fpermissive -D__STRICT_ANSI__ -I “F:/—OGRE/ogre_src_v1-8-1/include” -I “F:/—OGRE/ogre_src_v1-8-1/OgreMain/include”
I don’t think this is a good idea. Most configure systems will pull CFLAGS or similar from the environment or from their command-line arguments. You should just use that.
scan-build make CFLAGS=-D__STRICT_ANSI__
- If it happens so that both gcc and Clang are used after configuration then they share the same set of flags and the problem increases - Clang do not recognize some of gcc flags.
So I wish to add another option to scan-build, (e.g. CLANG_EXCLUDE_CXXFLAGS in config file) that will hold flags to be excluded from Clang invocation.
Last I heard we still strive to be GCC-compatible, so we should accept and warn/ignore any flags that GCC supports that we don’t. But I can see how that doesn’t solve the problem for a local user.
- The third option is to add a possibility to completely bypass compilation step by gcc(g++, etc.) - this partially solves problems with options and, what is more important, may significantly reduce overall analisys time.
Seems fair. It should still default to off (and we have to figure out if we can support it in Xcode), but it seems like a reasonable option.
Jordan
Hi all,
I’m thinking of the following improvements to scan-build and want to discuss them with the community and to hear your thoughts and opinions:
First of all, refactoring: keep all scan-build arguments in the hash rather then in scattered variables.
This will make the scan-build code easier to understand and make it easier to re-engineer the code in the future.
I’m not convinced of this. Either you have scattered options globally, or you have options in one place looked up by scattered string keys. I’d honestly prefer the globals because they’ll let me know if I have a typo.
Then I intend to add a possibility for scan-build to read options from a simple INI-like (http://en.wikipedia.org/wiki/INI_file) configuration file.
Values (if any) from this file will override default hardcoded values but do not override those obtained from the command line.
The file may have separate sections for scan-build, ccc/c+±analyzer and environment variables (if needed).
This will concentrate all the analyzer settings in the single place and will allow users to easily observe the default values all-together and to customize scan-build invocations of their own will.
This seems reasonable. At the very least recording specific checkers to turn on or off makes sense. On the other hand, if it’s just things that can be controlled on the command line, does it really offer that much more flexibility than someone writing their own wrapper scan.sh / scan.bat?
I also intend to add several additional options to scan-build:
- Set of additional flags for ccc/c+±analyzer (e.g. additional include paths, defines, optimization options, e.t.c).
Often after ‘configure’ analysys with Clang ended up with different errors and I had to manually patch makefiles to transfer additional flags to Clang to make it work. It was a real headache.
Here is random example of how this additional flags looked like: ‘-g0 -Os -fpermissive -D__STRICT_ANSI__ -I “F:/—OGRE/ogre_src_v1-8-1/include” -I “F:/—OGRE/ogre_src_v1-8-1/OgreMain/include”’…
So many times I wished to put extra flags somewhere so that ccc/c+±analyzer could take them and pass to Clang!
In configuration file it might look like the following:
CLANG_EXTRA_CXXFLAGS = -g0 -Os -fpermissive -D__STRICT_ANSI__ -I “F:/—OGRE/ogre_src_v1-8-1/include” -I “F:/—OGRE/ogre_src_v1-8-1/OgreMain/include”
I don’t think this is a good idea. Most configure systems will pull CFLAGS or similar from the environment or from their command-line arguments. You should just use that.
scan-build make CFLAGS=-D__STRICT_ANSI__
- If it happens so that both gcc and Clang are used after configuration then they share the same set of flags and the problem increases - Clang do not recognize some of gcc flags.
So I wish to add another option to scan-build, (e.g. CLANG_EXCLUDE_CXXFLAGS in config file) that will hold flags to be excluded from Clang invocation.
Last I heard we still strive to be GCC-compatible, so we should accept and warn/ignore any flags that GCC supports that we don’t. But I can see how that doesn’t solve the problem for a local user.
- The third option is to add a possibility to completely bypass compilation step by gcc(g++, etc.) - this partially solves problems with options and, what is more important, may significantly reduce overall analisys time.
Seems fair. It should still default to off (and we have to figure out if we can support it in Xcode), but it seems like a reasonable option.
I’d like to clarify this point a bit. Some builds rely on the result of compilation. So if this option was added, it would be turned off by default. I agree with Jordan that the approach we should take is to teach scan-build about the options that need to be ignored when calling “clang --analyze”. I think this is what it is already doing.
Also, note that build time is usually small in comparison to the analysis time.
I’ll think this over. May Class::Struct fit or just simple options renaming. As for me I got tired copying this wrappers with repetitive options around 
All my scan-build invocations start with ‘-v -v -v -o “./” --use-analyzer=F:/llvm_COMMON/-Eclipse_build-/Release+Asserts/bin/clang.exe -analyze-headers’. I’d be glad to move this to config. Not CFLAGS but some special variable known only for scan-build and ccc/c+±analyzer scripts. This variable doesn’t need to be an environment variable, ccc/c+±analyzer may read its value directly from the configuration file. This flags must be given to Clang only, not GCC or other compiler. Ok, I’ll explore the behavior of clang with --analyze more carefully. I’ve faced an unsupported option while trying to build QT, unfortunately can not find what this option was. The idea to move this setting to config was to give the user more freedom in customization (for example if the user face an unsupported flag that is not handled by “clang --analyze” logic then he can simply disable passing this option to clang using config file). The second reason for adding this option to config were my dim memories about non-analyzer specific flags that affected analyzer behavior. I may be mistaken here. Perhaps this were optimization options. I thought It would be good to have an ability to disable this options.