library porting question - optional python bindings

[Chris Inacio]

On Tue, Mar 1, 2016 at 3:04 AM, Shane Ambler <FreeBSD at shaneware.biz> wrote:

> On 01/03/2016 13:08, Chris Inacio wrote:
>
>> All,
>>
>> I'm trying to build a port definition for a library/application that can
>> optionally include Python bindings.  The library/application generally
>> depends on other C libraries to exist (ZMQ v3, Protobufs-C) and if you
>> enable Python support, then you need a Python interpreter plus
>> Python-protobufs & python zmq.
>>
>> Putting an OPTION of Python in the port file is easy.  Including the
>> optional Python dependencies (and presumably targets - but I'm not that
>> far
>> yet) seems to be a lot more complicated.  I haven't found anything that
>> would tell me how I'm supposed to do that.  I have found that I'm supposed
>> to add pyXX prefixes to the python targets.
>>
>
> Python bindings as in a module that can be imported in python? or
> python bindings that help the lib linking to it to be exposed to python?
>
> The difference is a python module will be installed into
> pythonx.y/site-packages while the other will install lib/libxxx.so
>
> devel/boost-python-libs is an example of the later.
>
> For a normal python module I would suggest making it as a separate port
> that just installs the python module. This makes it easier to install
> multiple versions for each python version. The py-module port can be a
> slave of the main port so you don't have to maintain the same code
> twice.
>
> A port with PORTNAME=nose and PKGNAMEPREFIX=${PYTHON_PKGNAMEPREFIX}
> can then end up with multiple installs to support each python version.
>
> pkg info -ox nose
> py27-nose-1.3.7                devel/py-nose
> py34-nose-1.3.7                devel/py-nose
> py35-nose-1.3.7                devel/py-nose
>
> Does anyone know of a similar application/library that I can go look at?
>> Is there any documentation on how to solve this?
>>
>
> I have graphics/openimageio and py-openimageio as well as
> graphics/opencolorio that has opencolorio-tools and py-opencolorio as
> slaves.
>
> openimageio uses SLAVE_PORT as defined by the ports infrastructure
> while opencolorio defines it's own OCIO_SLAVE to distinguish between
> the two slaves
>
> Using VARIABLE?=xxx in the master Makefile allows the slave port to
> override that variable.
>
> --
> FreeBSD - the place to B...Software Developing
>
> Shane Ambler
>
>
The library is generally a C library with 3 "targets" a library (.so),
header files (.h), and daemon that can be used as well.

If you enable the optional Python support, then there is an entire python
build area with the full "python setup.py ..." that gets run *from the C
Makefile* when the Python dependencies are available.

So yes, I can see that it makes sense to have this has 2 separate ports
from a port maintenance point of view, but this is distributed as a single
distribution.

So you're suggesting 2 ports, from one source download, and 1 of those
ports dependent on the other port?