KDEPIM4 and gpgme: header conflict

[RJVB (René Bertin)]

So, the sequel to ticket:52342...

Half a night and day of rebuilding later, I am now convinced that the most reasonable and efficient way forward is to patch port:gpgme and port:kdelibs4 such that the 2 incompatible gpgme++ versions have their own include directories from which the compiler shouldn't normally read headers by accident. IOW, -I${prefix}/include/KDE or -I${prefix}/include/gpgme is required to select the appropriate header source directory.

KDE clearly intend to maintain their own gpgme++ wrappers for the time being, which means they must have a reason that we should consider as certainly good enough for us (= not to try and patch KDE code).

The companion ticket that proposes the required patch to port:gpgme : attachment:ticket:52479:gpgme.diff​

@Nicos: let me repeat that moving the KDE4 headers to ${prefix}/include/KDE4 is both simple and required for compatibility with my upcoming KF5 ports. Almost all that is required is rebuilding port:kdelibs4 with -DINCLUDE_INSTALL_DIR=${kde4.include_dirs} in configure.args . No dependents need to be rev-bumped, all dependents will find the moved kdelibs4 headers, and all but a select few will install their own headers there too (= the -DINCLUDE_INSTALL_DIR=${kde4.include_dirs} configure arg. doesn't have to be repeated for all dependents). If you want to test this more fully it should be possible to add that configure arg. to the KDEPIM4 ports only, for now. I haven't tested this.

PS: I also have kdepim*-devel ports in my MacStrop repo that update KDEPIM4 to the very latest version.

[larryv (Lawrence Velázquez)]

Please don’t set ticket priority; that is for committers to decide.

[RJVB (René Bertin)]

Ok then - Marko, if you agree with the priority I set, can you please set it back? O:-)

[larryv (Lawrence Velázquez)]

Port failures are very rarely designated as high priority.

[StanSanderson]

Cc Me!

[jjstickel (Jonathan Stickel)]

Cc Me!

[NicosPavlov]

Just my two cents as the supposed maintainer of kdepimlibs4. This port has been installing its own version of the gpgme headers for its internal use. Its seems logical to me that we should move kdepimlibs4 files out of the way to leave the "general" ones in their standard place.

KDE provides its own FindGpgme.cmake file for finding its components. Hopefully I could tweak it so that the other KDE ports could find the internal KDE headers and libraries.

[NicosPavlov]

I'll just try to answer to the different issues one by one.

Issue 1: Which gpgme headers to use

I agree that using the newer gpgme headers as done in my previous commit is probably not a good approach, especially as dependent ports build on that. I'll reinstate the files, and move them elsewhere to not conflict with gpgme ones. As said above, I think it should be possible to tweak the FindGpgme file so that other ports will find what they need.

Issue 2: Move all KDE4 headers to another location

I do know that you proposed this, and I did look at it, and already said that I could do it. However, to the best of my knowledge (and correct me if I am wrong), the addition of the KF5 ports is hindered lower in the chain due to for instance conflicts between needed versions of qt5. I would like to make these changes when and if they are useful, not for the beauty of it.

PS: I also have kdepim*-devel ports in my MacStrop repo that update KDEPIM4 to the very latest version.

Even if these are the latest versions, how does it solve the issue at hand with the official latest releases?

[RJVB (René Bertin)]

Replying to nicos@…:

Just my two cents as the supposed maintainer of kdepimlibs4. This port has been installing its own version of the gpgme headers for its internal use. Its seems logical to me that we should move kdepimlibs4 files out of the way to leave the "general" ones in their standard place.

KDE provides its own FindGpgme.cmake file for finding its components. Hopefully I could tweak it so that the other KDE ports could find the internal KDE headers and libraries.

As I said, it should be possible to achieve this by adding an appropriate -DINCLUDE_INSTALL_DIR to the configure.args. A priori that should only be necessary for kdepimlibs4, but it might be better to do it for all KDEPIM4 ports. And frankly, if you're going that way, I'd advise to do it for all KDE4 ports by applying the setting to kdelibs4 (see also below).

I would also strongly advise to be very careful tweaking that FindGpgme.cmake file (or any other cmake file of similar complexity). There is no need for that if you follow my advise, maybe the same applies to using -DINCLUDE_INSTALL_DIR only for the KDEPIM ports. FindGpgme.cmake tries to locate the headers by searching for gpgme.h in the current include search path and in ${prefix}/include . You could patch that 2nd line, but it should be possible to include the necessary path in CMAKE_INCLUDE_PATH without patching anything. I'm pretty sure that's what happens when you configure kdelibs4 with -DINCLUDE_INSTALL_DIR=/opt/local/include/KDE4 .

    find_path( GPGME_INCLUDES gpgme.h
      ${CMAKE_INCLUDE_PATH}
      ${CMAKE_INSTALL_PREFIX}/include
    )

Issue 1: Which gpgme headers to use

I agree that using the newer gpgme headers as done in my previous commit is probably not a good approach, especially as dependent ports build on that. I'll reinstate the files, and move them elsewhere to not conflict with gpgme ones. As said above, I think it should be possible to tweak the FindGpgme file so that other ports will find what they need.

May I request that you use the path I've been testing, ${prefix}/include/KDE4 ? It's not used for anything else, and is an appropriate choice given that KF5 installs its headers into ${prefix}/include/KF5 .

Issue 2: Move all KDE4 headers to another location

I do know that you proposed this, and I did look at it, and already said that I could do it. However, to the best of my knowledge (and correct me if I am wrong), the addition of the KF5 ports is hindered lower in the chain due to for instance conflicts between needed versions of qt5. I would like to make these changes when and if they are useful, not for the beauty of it.

Yes, in order for the KF5 ports to work as intended they require a dedicated (patched) Qt5 port. That however is a lot easier to accomplish; we're getting the final kinks out of port:qt5-kde (which are in fact due to 10.12 and Xcode 8, not to the port itself), for the rest it is ready to be committed. So in a sense the KDE4 header issue is more of a blocker than the question of which Qt5 port to use. I think that particular change has been useful for a while now already; it would have allowed Marko to test the KF5 ports with "bone stock KDE4" ports installed, for instance.

PS: I also have kdepim*-devel ports in my MacStrop repo that update KDEPIM4 to the very latest version.

Even if these are the latest versions, how does it solve the issue at hand with the official latest releases?

It doesn't, sadly. Those latest versions are still too old. They do resolve quite a few other issues though. Hence the "PS".

---

Now, as to getting kdepim4libs to build using the headers from port:gpgme . I've begin looking at that by linking /opt/local/include/KDE4/gpgme++ -> /opt/local/include/gpgme/gpgme++ and providing a single header from kdepimlibs4 that gpgme doesn't provide (gpgme++_export.h). Doing that I am left with only a handful of compiler errors:

/opt/local/include/KDE4/gpgme++/gpgsetexpirytimeeditinteractor.h:26:10: error: 'editinteractor.h' file not found with <angled> include; use "quotes" instead
/opt/local/var/macports/build/_opt_local_site-ports_kde_kdepim4-devel/kdepim4-devel/work/kdepim-4.14.git/libkleo/backends/qgpgme/qgpgmechangeexpiryjob.cpp:73:37: error: no viable conversion from 'std::auto_ptr<EditInteractor>' to 'std::unique_ptr<EditInteractor>'
/opt/local/include/KDE4/gpgme++/gpgsetownertrusteditinteractor.h:26:10: error: 'editinteractor.h' file not found with <angled> include; use "quotes" instead
/opt/local/include/KDE4/gpgme++/gpgsetownertrusteditinteractor.h:27:10: error: 'key.h' file not found with <angled> include; use "quotes" instead
/opt/local/var/macports/build/_opt_local_site-ports_kde_kdepim4-devel/kdepim4-devel/work/kdepim-4.14.git/libkleo/backends/qgpgme/qgpgmechangeownertrustjob.cpp:65:37: error: no viable conversion from 'std::auto_ptr<EditInteractor>' to 'std::unique_ptr<EditInteractor>'
/opt/local/include/KDE4/gpgme++/gpgsignkeyeditinteractor.h:26:10: error: 'editinteractor.h' file not found with <angled> include; use "quotes" instead
/opt/local/var/macports/build/_opt_local_site-ports_kde_kdepim4-devel/kdepim4-devel/work/kdepim-4.14.git/libkleo/backends/qgpgme/qgpgmesignkeyjob.cpp:77:37: error: no viable conversion from 'std::auto_ptr<EditInteractor>' to 'std::unique_ptr<EditInteractor>'
/opt/local/include/KDE4/gpgme++/gpgadduserideditinteractor.h:26:10: error: 'editinteractor.h' file not found with <angled> include; use "quotes" instead
/opt/local/var/macports/build/_opt_local_site-ports_kde_kdepim4-devel/kdepim4-devel/work/kdepim-4.14.git/libkleo/backends/qgpgme/qgpgmeadduseridjob.cpp:70:37: error: no viable conversion from 'std::auto_ptr<EditInteractor>' to 'std::unique_ptr<EditInteractor>'

Those are errors that would require patching the gpgme headers (accessed here via /opt/local/include/KDE4/gpgme++), which kdepimlibs4 evidently cannot do, so I guess my experiment ends there. Also, the fact that the code compiles doesn't mean it will link, or even if it does, run without crashing due to subtle ABI mismatches.

[RJVB (René Bertin)]

(continuing from comment:11:ticket:52479)

As I tried to explain, the various -I and -isystem options are all given in one big set of command line arguments when you finally invoke the compiler, and they're not in any way linked at that point to specific include files. IOW, there's no way to tell the compiler to get a particular header from directory B but not directory A if both have to be on the search path.

It also wouldn't make sense for a compiler to search directory A ten times if it has been passed in that many times with -I or -isystem. So I think what happens is that the compiler compiles all those search locations into a single graph which is then sorted to correspond to the actual directory layout. IOW, if you specify both /opt/local/include and /opt/local/include/KDE4 (and you have to), the higher-up directory will be searched first, and so /opt/local/include/gpgme++/foo.h would be found and not /opt/local/include/KDE4/gpgme++/foo.h .

NB: this form or prioritising instead of doing it the other way round makes sense : there are quite a few system headers that do things like /usr/include/signal.h which includes /usr/include/sys/signal.h . Suppose someone does -I /usr/include/sys for an obscure reason; this probably should not cause #include <signal.h> to include sys/signal.h .

[hjs@…]

Cc Me!