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!

[NicosPavlov]

I think I got things to compile correctly. Kdepimlibs4 is now moving the conflicting headers away, and dependent ports find them properly. As trying to use something general such as CMAKE_INCLUDE_PATH did not work (as pointed before the other headers were found first), I patch the relevant places to force GPGME_INCLUDES to the right location. It somewhat a hack, but works for a single location and only a few ports as in this case.

I made a quick round of compilation with the other KDE ports, I found that kget had a similar issue, which could be fixed in the same way. With this, we should be good to go.

[NicosPavlov]

I'll submit the portfiles in a moment, but here are the changes, along with the example of kdepim4, in case there are suggestions before committing. Please ignore patch-kdepim4.2.diff, I had a double-click syndrome.

[RJVB (René Bertin)]

• you'll want to correct the typo in the kdepimlibs4 patch, to make it work on case-sensitive systems:

          move ${destroot}${prefix}/include/gpgme++ \ 
   	68	            ${destroot}${prefix}/include/kde4/gpgme++ 
  

Frankly, I'm surprised you've managed to get the compiler to avoid the gpgme++ headers from ${prefix}/include/gpgme++ . I haven't yet tried to understand how, but I hope this it's reliable.

Do you need to disable Kleopatra? I'm not 100% sure if it's indeed indispensable but in my experience KMail relies on it for managing certificates.

[NicosPavlov]

Replying to rjvbertin@…:

• you'll want to correct the typo in the kdepimlibs4 patch, to make it work on case-sensitive systems:

          move ${destroot}${prefix}/include/gpgme++ \ 
   	68	            ${destroot}${prefix}/include/kde4/gpgme++ 
  

Alright. "kde4" was also my first choice, but I took the uppercase based on your own suggestions. Lowercase it is, then. EDIT: Sorry, missed your point. I'll fix the typo for uppercase.

Frankly, I'm surprised you've managed to get the compiler to avoid the gpgme++ headers from ${prefix}/include/gpgme++ . I haven't yet tried to understand how, but I hope this it's reliable.

Yes, I think it is. This approach forces the include path specifically, so that the compiler does not search elsewhere. I wondered if even a "-DGPGME_INCLUDES" argument could work, but I preferred tackling the issues specifically to know where they are.

Do you need to disable Kleopatra? I'm not 100% sure if it's indeed indispensable but in my experience KMail relies on it for managing certificates.

This is from a while ago, so I won't address it these commits. You can refer to the bug report in the comment.

[NicosPavlov]

kdepimlibs4 committed in r153162, dependents (kde4-runtime, kdepim4, kget) done in r153563.

[RJVB (René Bertin)]

Replying to nicos@…:

Alright. "kde4" was also my first choice, but I took the uppercase based on your own suggestions. Lowercase it is, then.
EDIT: Sorry, missed your point. I'll fix the typo for uppercase.

WHEW!

Yes, I think it is. This approach forces the include path specifically, so that the compiler does not search elsewhere. I wondered if even a "-DGPGME_INCLUDES" argument could work, but I preferred tackling the issues specifically to know where they are.

The problem is of course that the compiler most likely *has* to search in ${prefix}/include ...

[Polyergic (Shad Sterling)]

Cc Me!