Distribute the GpgME bindings separately from GpgME
Closed, WontfixPublic

Assigned To
Authored By
• ikloecker
May 6 2024, 9:44 AM
Tags

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.