The CI is still missing libkleo on Windows though it seems, so akonadi-contacts no longer builds there now. Is anyone looking into sorting that out already? @mlaurent @dvratil

@mlaurent has jumped into it without talking to me or others :( I suggest we revert this, as libkleo depends on gpgme++/qgpgme which can as of now be only built using a hack in Craft. Getting this in Windows CI proper may require some more work.

I can't even build the entire Kontact in Craft without some extra hacks that I haven't upstreamed yet.

Wierd it compiles in local. We fixed some compile error with Hannah. So now we can build with craft kmail/akregator/ and I worked at the moment on korganizer. So I don't understand why it doesn't build for CI at the moment.

The problem is that the CI is simply missing libkleo as a dependency altogether, there is no build configured for it. I assume that this is because gpgme++ is/was not available, and thus libkleo didn't build. So this is most likely a matter of adding the relevant parts to the CI system, not a code change in here.

I added gpgmepp in craft rule. I think it will help CI

ci uses a older image generated from craft, I'll bring https://binary-factory.kde.org/view/Management/job/Craft_Build_Master_Cache_windows-msvc2019_64-cl-debug/ back to operation and then you need to convince @bcooksley to update the image

libkleo was blacklisted by me a while back in sysadmin/ci-tooling@603a348f

Just adding gpgme may not be enough, as libkleo needs the C++ bindings and gpgme to my understanding has to be built with MingW, which means the ABI won't match (due to mangling differences between MSVC and MingW) and meaning that everything in the PIM stack would have to be built with MingW (which the existing CI setup is not equipped for at this time)

I managed to get the C++ and Qt bindings to compile with MSVC by adding patches to the Craft blueprint (or rather by adding a new blueprint) for gpgme, so it is now possible to build libkleo using Craft. So if all necessary parts in Windows CI get updated, we should be able to build libkleo there soon.

Still, I think we should revert this, wait for successful build of libkleo on Windows CI, then we can start looking into re-applying this commit and enabling further PIM components to build there in order to disrupt CI operation as little as possible.

mentioned in merge request !4 (closed)

@mlaurent what is the status of reverting the commit? Can I do it?