Porting software that wants to build/install its own language bindings

[Mojca Miklavec]

On 29 November 2016 at 02:21, Lawrence Velázquez wrote:
>> On Nov 28, 2016, at 7:31 PM, A. Karl Kornel wrote:
>>
>> I am looking for advice on how best to handle a port for a program
>> that wants to build its own language bindings.
>>
>> I am writing a port for a program called "hivex", which is a tool and
>> an API for manipulating Windows Registry "hive" files.  The API is
>> written in C, but it also is able to build support for Perl, Python,
>> OCaml, and Ruby.
>>
>> What makes this confusing is that additional language support is added
>> by `configure` switches (like --with-python and --without-ocaml), so
>> I don't think separate Portfiles would be the best option here.  I'm
>> also not sure if subports would work either.

Did you check what exactly these options change?

In case of OCaml I would just provide a variant that would allow
someone to avoid a dependency on OCaml.

In case of Perl, Python, Ruby, ... I would first check what exactly
the port installs and what it offers. If the bindings are meant to be
used in *other* software, like for example in a perl or python script
that a user writes himself, then supporting subports like p5.24-hivex
(and p5.26-hivex once a new version of perl gets released) would make
more sense. Sadly, if the upstream doesn't offer any easy way to do
that, you would have to compile the whole software and just put the
relevant bits to destdir.

If you just need Perl in the port itself, it makes more sense to
provide a variant.

> As Brandon already said, it's common to use variants for this. Ports
> that do this include boost, postgresql*, root[56], xapian-bindings, and
> vim/MacVim (among many others).

ROOT is a particularly bad example (I would say a counterexample) of a
port using python variants.

I would say that there are two kinds of ports that require python:

1.) Ports that simply need *any* version of python to be functional
    1.A) among those ports where support for Python 3 is still
experimental (and developer might want to be able to experiment and
report problems upstream)
    1.B) or ports where python is optional
2.) Ports that install python modules that are useful elsewhere

In the first case using a variant is much better (or no variant at all
if any version of python just works). In the second case it's better
to use subports.

In case of ROOT, the port installs a python module that is supposed to
be used in standalone python scripts written by users. So it would be
much much better if the port would be split into
- root6
- py27-root6
- py35-root6
etc.

The problem is that it's non-trivial to install py**-root[56] outside
of the main installer. It would be super easy if upstream would
support that. At the moment the only way other that diving into the
source and make heavy modifications would be to compile root[56] four
times, once for the main port and three other times for three python
subports. And then remove anything that's already installed by the
main port in post-destroot phase. But that would be super resource
hungry (compiling root6 means compiling the latest clang + many more
classes).

> A few ports do use subports or separate ports; these include
> subversion-* and swig. If you can manage it, this setup is best because
> other ports can then declare dependencies on your bindings (they cannot
> properly depend on variants), but it might require more work on your
> part. Depending on the build system, each subport might have to do
> a full build while only installing the bindings and discarding
> everything else.

Yes, sadly that might sometimes be the only option. If it's built on
the buildbot or if the software is small enough, that's a bit less of
a problem for your users.

Mojca