I've been working on my primary use-case for the gcc-python-plugin:
finding bugs in C Python extension code.
To that end, I've been attempting to automate a mass rebuild of all of
the C Python extension code in Fedora, building it with the cpychecker
code [1]. The source tree has recently grown a "misc/fedora"
subdirectory, and within it there's a mass-rebuild.py script which
attempts to rebuild a set of source packages (within chroots), injecting
the gcc python plugin and the libcpychecker code into the build. It
then slurps out all of the refcount-error.html files from the chroot
into a results directory.
On doing so, I'm running into the very real issue of what to do with all
the errors that the plugin finds: some packages have dozens of errors.
I want to provide something that an upstream maintainer of a python
package can look at and understand, without subjecting them to a wall of
noise.
To that end, I've built a triaging script which walks over the results,
and tries to triage them into high-severity through low-severity
categories, and writes out an index.html indexing them all.
You can see an example of all of this here, where the cpychecker code
has analyzed the python bindings for GStreamer:
http://people.fedoraproject.org/~dmalcolm/gcc-python-plugin/2012-02-10/gs...
Thoughts?
Hope this looks sane
Dave
[1] I'm tracking this for Fedora here:
http://fedoraproject.org/wiki/Features/StaticAnalysisOfPythonRefcounts