Page MenuHome GnuPG

GpgME++ / QGpgME MSVC build
Open, NormalPublic

Description

Ever since we migrated GpgME++ and QGpgME its been a problem that these two binaries from Gpg4win don't integrate with MSVC Software.
We need this now at least to support GPGME integration in the AppStore MSVC build of Okular.
With the change to signed / encrypted attachments this was apparently also an added problem for Applications using these libraries.

Libreoffice has its own build system and some patches https://github.com/LibreOffice/core/tree/master/external/gpgmepp

I think Craft or at least @dvratil had some patches too to add a CMake build system on it. We could probably also life with a static Makefile.MSVC or something like that.

We would maintain the autotools build system of course, too and use that for our releases as it is important for us that our Software is built with Open Source tools.

Ingo you also mentioned interest in this, from sune I know that he currently has a craft setup for building so maybe sune would be the closest one to take this up?

Event Timeline

aheinecke triaged this task as Normal priority.Jul 10 2023, 12:12 PM
aheinecke created this task.

I was able to find the Craft blueprint with the CMake build system in my Win VM and pushed it to invent: https://invent.kde.org/packaging/craft-blueprints-kde/-/commit/5e9aae4d006f69657d3612c2fe398c9e5ae69ac0, feel free to use it for inspiration or base for future work, or ignore it completely :). It's probably far from a production-ready CMake script, some years ago I just really really *really* wanted to build KMail on Windows (don't ask why) so I did some unspeakable evils to make it happen. This is one of the better things that came out of it...

One complication comes from the fact that gpgmepp and qgpgme include the global config.h that is generated by configure. This needs to be replaced. I'll attach two files where I grepped for usage of the config.h's #defines (generated on Linux) in lang/cpp and lang/qt. The files probably contain false positives.


@ikloecker I think your logs contain only false positives, I do not know that we use any defines created by config.h. Maybe for gpgme_off_t but even so when I moved gpgme++ and qgpgme from kdepimlibs into the GPGME repo I did not add any defines to configure for that.

This is now mostly done. These 3 patches make it work:

We just need to properly integrate then upstream and then KMail with the help of a few other patch in the stack can be built on Windows :)

We have discussed this yesterday. The idea/plan is to release the core library and the bindings as separate tarballs (created from the same repo) in the future.

Consequently, there should be "standalone" cmake files in lang/cpp and in lang/qt, but none in the root folder or the lang folder. Both cmake files should assume that their dependencies (i.e. gpgme and, in case of the Qt bindings, also gpgmepp are already installed).