<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Thanks for looking at this!<br>
<br>
</div>
<blockquote
cite="mid:528A92F4-DF1C-4D13-9A7E-A1EEE5365D9C@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Nov 6, 2014, at 9:35 AM, Jordan Rose <<a
moz-do-not-send="true" href="mailto:jordan_rose@apple.com"
class="">jordan_rose@apple.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;" class=""><br
class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Oct 27, 2014, at 13:30 , Anton
Yartsev <<a moz-do-not-send="true"
href="mailto:anton.yartsev@gmail.com" class="">anton.yartsev@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">Hi all,<br class="">
<br class="">
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:<br
class="">
<br class="">
First of all, refactoring: keep all scan-build
arguments in the hash rather then in scattered
variables.<br class="">
This will make the scan-build code easier to
understand and make it easier to re-engineer the
code in the future.<br class="">
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">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.</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
I'll think this over. May Class::Struct fit or just simple options
renaming.<br>
<br>
<blockquote
cite="mid:528A92F4-DF1C-4D13-9A7E-A1EEE5365D9C@apple.com"
type="cite">
<div>
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;" class="">
<div class="">
<div class=""><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class=""><br class="">
Then I intend to add a possibility for scan-build to
read options from a simple INI-like (<a
moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/INI_file"
class="">http://en.wikipedia.org/wiki/INI_file</a>)
configuration file.<br class="">
Values (if any) from this file will override default
hardcoded values but do not override those obtained
from the command line.<br class="">
The file may have separate sections for scan-build,
ccc/c++-analyzer and environment variables (if
needed).<br class="">
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.<br
class="">
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">This seems reasonable. At the very least
recording specific checkers to turn on or off makes
sense. On the other hand, if it's <i class="">just</i> 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?</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
As for me I got tired copying this wrappers with repetitive options
around :)<br>
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.<br>
<br>
<blockquote
cite="mid:528A92F4-DF1C-4D13-9A7E-A1EEE5365D9C@apple.com"
type="cite">
<div>
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;" class="">
<div class="">
<div class=""><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class=""><br class="">
I also intend to add several additional options to
scan-build:<br class="">
1) Set of additional flags for ccc/c++-analyzer
(e.g. additional include paths, defines,
optimization options, e.t.c).<br class="">
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.<br class="">
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"'...<br
class="">
So many times I wished to put extra flags somewhere
so that ccc/c++-analyzer could take them and pass to
Clang!<br class="">
In configuration file it might look like the
following:<br class="">
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"<br
class="">
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">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.</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
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.<br>
<br>
<blockquote
cite="mid:528A92F4-DF1C-4D13-9A7E-A1EEE5365D9C@apple.com"
type="cite">
<div>
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;" class="">
<div class="">
<div class=""><br class="">
</div>
<div class="">scan-build make CFLAGS=-D__STRICT_ANSI__</div>
<div class=""><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">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.<br
class="">
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.<br
class="">
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">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.<br
class="">
</div>
</blockquote>
</div>
<br class="">
<div class="">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.</div>
<div class=""><br class="">
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
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.</div>
</blockquote>
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.<br>
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). <br>
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.<br>
<br>
<blockquote
cite="mid:528A92F4-DF1C-4D13-9A7E-A1EEE5365D9C@apple.com"
type="cite">
<div><br class="">
</div>
<div>Also, note that build time is usually small in comparison to
the analysis time.</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">Jordan</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</blockquote>
<pre class="moz-signature" cols="72">--
Anton</pre>
</body>
</html>