Hello Nicolas,
I'm sure you've noticed that I'm making progress with ports for KF5. Maybe I
should have asked your opinion on how to approach this (if so, apologies that I
didn't), but I would like to know your thoughts on the issue of co-existence of
KDE4 and KF5 ports.
KF5 is designed to allow for step-by-step migration of applications from KDE4
to KDE5, but with the underlying idea that once an application has been
migrated it's the better version and users are not supposed to feel the need to
keep the older version around.
I have some issues with that premise and know of nothing in MacPorts that would
make it the default behaviour to force a choice between either KDE4 or KF5
versions of an application (fortunately, with all the inter-dependencies).
KF5 software doesn't leave a lot of leeway to configure it such that it won't
clash with KDE4 versions of the same, in line with said premise. Fortunately
most of the time the conflicts are limited to non-crucial things in
${prefix}/share, usually even things that were not changed w.r.t. their KDE4
version. So most of the time, the +kde4compat variant of a KF5 ports just omits
files that are already installed by the KDE4 version of the port.
There are however certain modifications that have to be made to (certain) KDE4
ports:
- The most frequent conflict occurs at the level of headerfiles. This can be
avoided very easily by building KDELibs4 with
-DINCLUDE_INSTALL_DIR=${prefix}/include/KDE4 . That puts the KDELibs headers
under include/KDE4 but also records the path in a cmake module, so that it is
inherited by all dependents.
The nice thing is that this change doesn't break binary compatibility, so I
have set it unconditionally in my KDE4 PortGroup; it gets applied when a port
is rebuilt.
- CMake modules are still an issue; I haven't yet found out a good way to
install them to ${prefix}/lib/cmake/KDE4 . I'm looking into simply moving the
files to a place outside the standard cmake include path (requiring
CMAKE_PREFIX_PATH to be set) ... but that will only protect against file name
clashes and against KF5 ports picking up cmake modules from KDE4 software :-/
- the biggest issue is with the libraries of some ports, e.g. kompare and
libkomparediff2 . While the runtime libraries (lib*.x[.y].dylib) are usually
distinguishable thanks to the version numbers, the linktime libraries
(lib*.dylib) aren't always. Or the developers had the brilliant idea to use
case, which means I won't always catch potential clashes because I use a
case-sensitive filesystem.
Either way, I am fine-tuning a mechanism to be used with +kf5compat, a set of
procedures where the 1st sets -DCMAKE_INSTALL_PREFIX=${kde4.legacy_prefix}
(${prefix}/libexec/kde4-legacy) and the optional 2nd procedure moves a number
of appropriate things back into ${prefix}. When you don't call that 2nd
procedure you end up with an installation that requires dependents to be built
with kf5compat too; fortunately it is enough to set CMAKE_INSTALL_PREFIX in
identical fashion to make the build work in that case.
I've had to patch port:kdelibs4 to install a symlink
(${kde4.legacy_prefix}/share -> ${prefix}/share) in order for this to work
perfectly, but everything indeed seems to work just fine like that, including
full transparency at runtime.
I haven't had to rebuild a single KDE4 port because one of its dependencies was
rebuilt using the hacks above, but that may just mean that I have yet to
encounter a problem port.
This is where I could use help from others who have KDE4 ports installed, the
more complicated the dependencies the better.
There is only so much time I can devote to checking existing KDE4 ports (which
do not yet have a KF5 version) against the compatibility changes I've been
making, in addition to the time I spend developing KF5 ports.
Help could come in 2 or 3 forms:
- install my KDE4 portgroup and port:kdelibs4. Check what effect that has on
your existing KDE4 ports; should be transparent. Check if that's still the case
after rebuilding them (supposing that works out OK). One set of ports that I
haven't rebuilt is akonadi/kdepimlibs,kdepim,kdepim-runtime because those are a
bit too crucial for me...
- idem, but also build the ports from my repository that have a +kf5compat
variant, with that variant selected. Again you should not notice any change.
- provide me with a reasonably fast and reasonably close-by (from France) VM on
which I experiment a bit more freely than on my own, single system. (I'm a bit
too late to leave hardware suggestions for Santa so I'll keep it at that ;))
Thanks for your attention :)
Cheers,
René
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
