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