Re: [PATCH] python: Add Python bindings for libgsasl

[David Michael]

On Tue, Jun 30, 2015 at 1:57 PM, Greg Troxel <address@hidden> wrote:
>
> From a packaging viewpoint, I don't think it matters whether it's in the
> upstream project or not.  But I would like to see it be buildable
> separately, so that one can build gsasl, and then from the same source
> tree with gsasl already installed, build the python module against the
> installed gsasl.  This is of course how a separate project would be.
> So perhaps it's just building in a subdir.

Building the module actually only consists of creating enum.py from
enumerations in gsasl.h, but the patch was designed so that a
pre-generated enum.py is provided in release archives from the
maintainer.  So the module files are basically static.  A simple
setup.py could be included to install the module using Python
distutils as an alternative to automake, but I stuck with automake
here just to keep the same build/install system everywhere.  (The step
that generates enum.py could also be removed in favor of just
providing the file and updating it in conjunction with gsasl.h,
similar to any other updates needed due to API changes, but then that
would add to the maintenance overhead.)

In terms of building enum.py against an installed libgsasl, it would
only need to be pointed at the installed gsasl.h.  That could be
located e.g. from the pkg-config file, but that wasn't really
available in the Windows build environment I had.  In that case,
building it in-tree against the known $(top_srcdir)/src/gsasl.h was
the easiest method.