Static src analysis of LibreOffice

Stephan Bergmann sbergman at redhat.com
Sun Aug 5 23:58:27 PDT 2012


On 08/03/2012 03:42 PM, John Smith wrote:
>> - Still lots of "external" stuff, dmake, libxmlsec/unxlngi6.pro,
>> workdir/unxlngi6.pro/LexTarget, ...
>>
> Well, the analyzer simply follows/precedes whatever you tell 'make' to
> do. So if the build includes 'make dbuild', then that *will* not only
> get build, but analyzed as well and show up in the report. I was
> hoping that adding '--with-system-libs' would solve that issue, but
> apparently it doesnt. If there are ./configure switches to disable
> compilation of those final parts - and Fedora pre-build system rpms to
> replace them -  then all should be fine. Or perhaps the rest of this
> 'external stuff' should be added to  '--with-system-libs', or get it's
> own ./configure switch ?

dmake will eventually be obsoleted by our new gbuild machinery and 
removed.  For the time being, it could help to start analyzing only 
after dmake has already been build (it is built in ./bootstrap, so 
something like "./autogen.sh && ./bootstrap && make" instead of just 
"make" might help).

workdir/unxlngi6.pro/LexTarget contains generated flex output, which 
itself is not external code, but the quality of that code, at least 
partly, is under the control of the external flex tool.  Something of a 
special case (hopefully leading to only a few reports anyway, which also 
might be worthwhile addressing in upstream flex if they are not false 
positives).

In any case, such stuff should be something we can filter out in some 
way (post-processing the data -- is it only available as HTML, or also 
in some other format?), so I wouldn't worry about it too much.  Just 
wanted to note it down...

Stephan


More information about the LibreOffice mailing list