Page MenuHome GnuPG

Distribute the GpgME bindings separately from GpgME
Closed, WontfixPublic

Description

We decided to distribute the GpgME bindings (C++, Qt, Python, etc.) separately from GpgME, i.e. there shall be tarballs for gpgme (the C library), gpgmepp (the C++ bindings), qgpgme (the Qt bindings), etc.

We will keep developing GpgME and its bindings in the same repository.

Event Timeline

ikloecker triaged this task as Normal priority.
ikloecker created this task.
ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

The current proposal has been pushed to the branch ikloecker/t7110-nested-bindings-packages.

Changes:

  • The C++, Qt and Python bindings can be configured and built together with gpgme (as nested packages). By default, the bindings are not configured and built.
  • The (default and custom) distribution targets package gpgme without the bindings.
  • The three nested bindings packages provide the same custom distribution targets as gpgme, i.e. one can run make dist, make release, etc. in lang/cpp, lang/qt, lang/python to package the bindings.
  • The top-level Makefile provides custom targets for packaging a single binding, e.g. dist-python, distcheck-python, release-python, sign-release-python, distclean-python.
  • The top-level Makefile provides custom targets for packaging gpgme and the three bindings (resulting in four tarballs): dist-all, distcheck-all, release-all, sign-release-all.

Current shortcomings:

  • gpgme (the C library) has to be installed, so that distcheck succeeds for the C++ and the Python bindings (because distcheck performs an isolated build of the C++/Python bindings which need to be able to find the required gpgme).
  • Similarly, gpgme and the C++ bindings need to be installed, so that distcheck succeeds for the Qt bindings.

Possible solution/variation:

  • We keep distributing everything with a single tarball, but keep the bindings as nested packages. The distribution targets for the nested packages will be removed/disabled because we don't want to distribute them separately. This solves/avoids the above shortcomings. External parties (e.g. distribution packagers) will be able to build gpgme and the bindings separately. In particular, this will simplify packaging of the Qt 5 and Qt 6 bindings.

gpgme and the C++, Qt 5 and Python bindings can be configured, built and installed with the following commands:

./autogen-all.sh  # runs autogen.sh for gpgme, lang/cpp, lang/qt and lang/python
mkdir build
cd build
../configure --prefix=/opt/gnupg/2.4 --enable-maintainer-mode --enable-languages="cpp qt python" --enable-qt-version=5
make
make check
make install

i.e. the only difference is that one needs to run ./autogen-all.sh instead of ./autogen.sh. And that one needs to enable the bindings and specify the Qt version. (By default, the Qt 6 are built if Qt 6 is found.)

Okay. Let us split it into different tarballs and repos. We will bump the gpgme core version to 2.0 to indicate this split despite that there will be non-ABI/API incompatibility. C++, Qt, Python will then go into separate projects. The old common List stuff will be kept in gpgme core for now. The gpgme core sticks with autoconf stuff but for C++ and Qt cmake style will be used instead.

ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.