[MacPorts] #52481: KDEPIM4 and gpgme: header conflict

[MacPorts]

#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