[gpgme] 1.7 build experience and issues

[Justus Winter]

Hello :)

Alon Bar-Lev <alon.barlev at gmail.com> writes:
>>> PYTHON
>>>
>>> If not absolutely required to have this in the same package, maybe it would
>>> be better to split it into a separate one that is to be used post
>>> installation of pgpme using pure python tools.
>>
>> Surely gentoo can produce several binary packages from one source
>> package?
>
> Well, it is not that simple.
> When you build several binary packages, each with several binary
> python you end up with somekind of deadlock.
> Either build the C bindings over and over for each python version or
> hack the package.
> Usually, there is no value in mixing the build of the C library and
> the python bindings into same build process and package. It is much
> easier to package both as separate packages that are built on after
> the other, without the need to hack the in-tree and multiple variants
> issues.

We disagree here then.

>> We are in fact using the python tools to build the bindings.  The checks
>> in configure merely try to detect which versions are available, and if
>> everything is in place to produce python modules with SWIG.
>
> Correct, however, the combination of autotools and distutils is what
> makes it more difficult.
>
> I sent a patch to clean this a bit to enable portage usage, however, I
> think that for generating the version into setup.py it is an overkill
> to use autoconf. You may consider taking this a bit farther to include
> version.py to be imported by setup.py, generate version.py as
> generated distributed source, this will skip the need to use configure

That was done before, however, including bits from the package in
setup.py is frowned upon and lead to a problem (I don't remember, maybe
the changelog mentions it), that's why I changed it to the way it is
done now.

> and make, with the exception of data.h which should have its own
> solution (moving away from in-tree build).

This needs a proper API, agreed.

>>> The autoconf ignores PYTHON override or any other attempt to use explicit
>>> environment.
>>> Please enable override to enable the packaging system to build the bindings
>>> to the supported python interpreters of the system.
>>
>> Gladly.  Can you please be more specific how that would look like?
>
> Oh... this is simple... if you use AM_PATH_PYTHON in autoconf, never
> unset its macros... :)

Well, that is not a very helpful answer.  We do use AM_PATH_PYTHON, and
we do reset the information it has gathered to be able to use it again.

Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: </pipermail/attachments/20160926/b0342626/attachment.sig>