#52481: KDEPIM4 and gpgme: header conflict --------------------------+--------------------- Reporter: rjvbertin@… | Owner: nicos@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: kdepimlibs4 | --------------------------+--------------------- Comment (by rjvbertin@…): Replying to [comment:8 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. -- Ticket URL: <https://trac.macports.org/ticket/52481#comment:10> MacPorts <https://www.macports.org/> Ports system for the Mac operating system