#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