[gpgme] 1.7 build experience and issues

[Alon Bar-Lev]

On 24 September 2016 at 02:39, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> On 23 September 2016 at 16:21, Justus Winter <justus at g10code.com> wrote:
>> Hi :)
>>
>> Alon Bar-Lev <alon.barlev at gmail.com> writes:
>>> I am the Gentoo maintainer of gpgme.
>>
>> thanks for the feedback.
>>
>>> FAILING TESTS
>>>
>>> t-sig-notation fails due to Unexpected notation data
>>
>> What version of GnuPG are you using as backend?
>>
>> We fixed a bug in GnuPG recently to properly report a notation flag, and
>> tightened the test case accordingly.  To support older versions of
>> GnuPG, the test tries to detect that an older version is used, but that
>> test might fail for some reason.
>
> $ gpg --version
> gpg (GnuPG) 2.0.28
> libgcrypt 1.7.3
>
>
>>
>>> 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 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
> and make, with the exception of data.h which should have its own
> solution (moving away from in-tree build).

I sent simplified version of the package, I did more distutils magic
at packager, and could live with simpler changes, I hope it is ok.

What I thought of doing (have no time right now):
1. setup.py to import version.py so that only setup's version.py is a
template (vs entire setup.py).
2. setup.py to add version as preprocessor macro (-Dxx=yy) to pass it
to C library without a need for additional template file.
3. pyme/version.py to obtain version from the C library at runtime.
4. use symlink instead of copy in Makefile.am, now that
pyme/version.py is not a template you can symlink entire pyme.

Please consider, I believe it will simplify the process.

>>> 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... :)
>
>>
>> Cheers,
>> Justus