[gpgme] 1.7 build experience and issues
justus at g10code.com
Mon Sep 26 10:51:13 CEST 2016
Alon Bar-Lev <alon.barlev at gmail.com> writes:
>>> 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
> 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
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
> 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
>>> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 454 bytes
Desc: not available
More information about the Gnupg-devel