https://bugzilla.redhat.com/show_bug.cgi?id=1578238
Bug ID: 1578238
Summary: Review Request: python-scan-build - A Clang scan-build
reimplementation in Python
Product: Fedora
Version: rawhide
Component: Package Review
Assignee: nobody(a)fedoraproject.org
Reporter: evan(a)eklitzke.org
QA Contact: extras-qa(a)fedoraproject.org
CC: package-review(a)lists.fedoraproject.org
Spec URL:
https://copr-be.cloud.fedoraproject.org/results/eklitzke/python-scan-buil...
SRPM URL:
https://copr-be.cloud.fedoraproject.org/results/eklitzke/python-scan-buil...
This package is a little weird and I need some help on it. I've broken this
down into a few parts below.
scan-build binary
~~~~~~~~~~~~~~~~~~~~~~~
Right now there is an official utility called scan-build which is part of LLVM.
One of the LLVM developers has been working on a Python reimplementation of
scan-build, which also has some extra features. This is likely to become the
official scan-build implementation in a future LLVM release.
The existing scan-build implementation is packaged in the clang-analyzer
package, which includes the following binaries:
/usr/bin/scan-build
/usr/bin/scan-view
My new package includes the following binaries:
/usr/bin/analyze-build
/usr/bin/analyze-c++
/usr/bin/analyze-cc
/usr/bin/intercept-build
/usr/bin/intercept-c++
/usr/bin/intercept-cc
/usr/bin/scan-build
As you can see there are new (and useful!) binaries in this Python
implementation. However, I will need to rename the /usr/bin/scan-build to avoid
conflicting with clang-analyzer. I'm open to suggestions on how to handle this.
License
~~~~~~~~~~~~~~
The license file used by this project is the same as LLVM, which is a custom
NCSA-like license. I looked at the llvm source package, and they just declare
the license there to be NCSA, so I did the same. The actual license can be
found here:
https://github.com/rizsotto/scan-build/blob/master/LICENSE.txt
noarch
~~~~~~~~~~~~~~
pyp2rpm thought this was a binary package because the setup.py file says it's
not zip-safe. Actually it works in kind of a strange way: the package includes
a file named ear.c, and the intercept-build binary compiles this on-the-fly
when wrapping builds. The ear.c file isn't actually built by setup.py. I
changed the spec file to be noarch which I think is correct, but I would like
someone to double check this.
My FAS username: eklitzke
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component