[
https://issues.apache.org/jira/browse/PROTON-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flavio Percoco updated PROTON-895:
----------------------------------
Attachment: (was: 0001-Rely-on-python-to-build-downloaded-tarball.patch)
> Rely on python to build the downloaded tarball
> ----------------------------------------------
>
> Key: PROTON-895
> URL: https://issues.apache.org/jira/browse/PROTON-895
> Project: Qpid Proton
> Issue Type: Bug
> Reporter: Flavio Percoco
> Assignee: Ken Giusti
> Attachments: 0001-Rely-on-python-to-build-downloaded-tarball.patch
>
>
> Recently, a patch that made python-qpid-proton's setup.py download proton-c
> and build it whenever it's not found in the system. The patch relied on cmake
> to build the library as everyone would do when building proton-c.
> While that works, it's not the right, most pythonic, reliable way to do it.
> Some reasons why it's not a good thing:
> 1. It might overwrite a system qpid install if there's one and if the
> python-qpid-proton library is being installed in the system
> 2. It requires users - including CI systems, etc - to have cmake installed.
> 3. It does everything from outside the Python mechanism.
> The patch proposed in this bug changes the current behavior in favor of using
> Python's build extensions to compile the library. The patch follows the same
> steps as you'd do with cmake and it does it *just* for the downloaded
> tarball. If there's an installed proton-c library, there's nothing to do. If
> you're building it using cmake from a proton-c dir, it'll keep using cmake
> normally.
> The built library doesn't have the same name as the global one and it's
> installed along with the python binding instead of installing header files
> and the library itself system wide.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
