[MacPorts] #50094: new ports: kf5-{libkomparediff2,kompare}

[MacPorts]

#50094: new ports: kf5-{libkomparediff2,kompare}
--------------------------+--------------------------------
  Reporter:  rjvbertin@…  |      Owner:  macports-tickets@…
      Type:  submission   |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+--------------------------------

Comment (by rjvbertin@…):

 In the current climate I'm not even going to hope to get something like
 this adopted by KDE. And even in a more friendly climate I doubt that this
 would get support: it is clearly their intention to push KF5 as a
 replacement for KDE4, so any application that gets ported is supposed to
 replace (and be better than) the older KDE4 version. It's already
 something that they allow applications to use KDE4 technology through the
 kdelibs4support framework.

 A good case in point is something I have observed in several packages now.
 The KDE4 versions of kompare, libkomparediff2 and grantlee have the
 possibility to configure where header files are to be installed; they end
 up there, and the respective cmake modules will reflect that location. The
 KF5 versions still have the CMake variable that is supposed to control the
 headerfile include directory, and it still controls the location of the
 headers, but the cmake modules do not take that setting into account. I
 have yet to determine whether that's a bug or a feature ...
 Sadly, installing the KDE4 versions in a dedicated prefix will have
 limited use as long as the KF5 headers of those packages have to be
 installed directly under ${prefix}/include. There's still a lot of chance
 that the compiler will pick up ${prefix}/include/kfoo/kfoo.h (KF5 version)
 rather than ${prefix}/include/KDE4/kfoo/kfoo.h.

 (BTW: An updated `port:grantlee` is pending submission.)

 Something else: co-existence appears to be perfectly possible when you put
 all of KF5 in its own prefix; I've been using my portfiles to install KF5
 into /opt/local on my KDE4-based Linux system too. It may help that
 MacPorts has been designed to avoid picking up things from outside the
 prefix, of course.

 Yes, the *compat variants are a bit of a kludge. The `kde4compat` variants
 in my KF5 ports have been almost exclusively about not reinstalling files
 already installed by the KDE4 version; in many cases we're talking about
 highly or completely identical files.
 The dylib you mention being removed is of course *not* the actual shared
 library. It's only the file that the linker will pick up, and removing it
 only means that  you cannot build dependent packages (cf. the `-dev`
 packages on Debian and Ubuntu). Or maybe you can with a minor change to
 the link command: if you have

 {{{
 libkfoo.dylib ->libkfoo.4.dylib ->libkfoo.4.14.dylib
 }}}

 then you can probably get the same result by linking with `-lkfoo` or
 `-lkfoo.4` .

-- 
Ticket URL: <https://trac.macports.org/ticket/50094#comment:2>
MacPorts <https://www.macports.org/>
Ports system for OS X