new ports: kf5-{libkomparediff2,kompare}

[RJVB (René Bertin)]

This is a submission for ports for the KF5 version of kompare and libkomparediff2, i.e. the current versions.

Changing the KDE4 versions so they can co-exist with their KF5 versions turns out tricky. For now I have made the ports conflicting unless a variant is set that removes the conflicting components, leaving only the runtime components. I was hoping for something a bit more elegant, but this ought to do for those who insist on having both installed, say for comparison purposes or because of dependencies on libkomparediff2 .

I may decide to propose using a dedicated prefix (${prefix}/libexec/kde4-legacy) where KDE4 ports that conflict with their KF5 counterparts can be moved.

KF5 clearly has the attitude that it replaces KDE4, keeping KDE4 compatibility only so not-yet-ported software can run under a KF5 "Plasma" desktop. Given the lack of maturity in many KF5 applications I'd really prefer to keep giving users the choice of keeping KDE4 versions around in addition to installing the newer KF5 versions which are the ones that get the new features.

[mkae (Marko Käning)]

A dedicated prefix sounds like the way to go, indeed! But it's probably requiring a lot of effort to get this done for all those ports around... From a user's point of view it would be more consistent to truly keep the coinstallability promise made for the underlying KDE4 and KF5 frameworks.

There *compat variants seem to be a rather strange workaround... I saw somewhere that there's even a dylib being wiped to get both versions installed!!

Perhaps you can come up with something which has a chance to be adopted by KDE's developers for inclusion in trunk?! I could imagine that they'd also want to achieve coinstallability for Linux as well...

[RJVB (René Bertin)]

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 .

[RJVB (René Bertin)]

OK, I have managed to create support for a legagy prefix in the KDE4 PortGroup (the kde4.include_prefix bit should already have been committed?!) :

# Install the kdelibs headerfiles in their own directory to prevent clashes with KF5 headers
set kde4.include_prefix KDE4
set kde4.include_dirs   ${prefix}/include/${kde4.include_prefix}
set kde4.legacy_prefix  ${prefix}/libexec/kde4-legacy

# Certain ports will need to be installed in "KF5 compatibility mode" if they are to co-exist
# with their KF5 counterparts. Call `kde4.use_legacy_prefix` to activate this mode, *before*
# the configure step is executed and taking care not to undo the effects
proc kde4.use_legacy_prefix {} {
    global prefix
    global kde4.legacy_prefix
    configure.pre_args-replace \
                    -DCMAKE_INSTALL_PREFIX=${prefix} -DCMAKE_INSTALL_PREFIX=${kde4.legacy_prefix}
    configure.args-replace \
                    -DCMAKE_INSTALL_RPATH=${prefix}/lib -DCMAKE_INSTALL_RPATH="${prefix}/lib\;${kde4.legacy_prefix}/lib"
}

# Call kde4.restore_from_legacy_prefix from the post-destroot phase of a port that uses
# KF5 compatibility mode. That mode is very indiscriminate, installing everything into the
# legacy_prefix initially. Most things will actually have to be moved back out into the
# regular prefix. This procedure automates what can be automated, but may also overshoot
# its goal.
# This procedure is bound to evolve.
proc kde4.restore_from_legacy_prefix {} {
    global destroot
    global prefix
    global kde4.legacy_prefix
    if {[file exists ${destroot}${kde4.legacy_prefix}/lib/cmake]} {
        # move back the cmake modules to where they should be
        file rename ${destroot}${kde4.legacy_prefix}/lib/cmake ${destroot}${prefix}/lib/cmake
    }
    if {[file exists ${destroot}${kde4.legacy_prefix}/lib/kde4]} {
        # move back the kparts and libexec content to where they should be
        file rename ${destroot}${kde4.legacy_prefix}/lib/kde4 ${destroot}${prefix}/lib/kde4
    }
    if {[file exists ${destroot}${kde4.legacy_prefix}/share]} {
        # move back the share directory to where it should be;
        # first delete the share directory that was created for us and should be empty:
        file delete -force ${destroot}${prefix}/share
        file rename ${destroot}${kde4.legacy_prefix}/share ${destroot}${prefix}/share
    }
}

With this, I can now install almost all of libkomparediff2 and kompare (KDE4 versions), except of course for the HTML handbook and the icons. See the updated diffs for the respective Portfiles.

Marko, can you double-check the PortGroup from my macstrop repo and commit it for me please?