Importing KDE Frameworks into the ports tree (required for newer KDE Desktop and Applications)

[tcberner]

Summary

KDE Frameworks is a collection of libraries and software frameworks by KDE
that serve as technological foundation for KDE Plasma 5 and KDE Applications
distributed under the GNU Lesser General Public License (LGPL). [1]

This imports 95% of the available KDE Frameworks into the ports tree.
The work is based on what we have in the KDE testing repo [2].

This is the next big step in updating the KDE Desktop and its Applications
to anything less dusty.

• Updates kde.mk
• Adds kf5-* ports
• Moves devel/extra-cmake-modules and replaces it with ours
• Fixes ports depending on ecm
• Todo: Update MOVED for ecm

[1] https://en.wikipedia.org/wiki/KDE_Frameworks
[2] http://src.mouf.net/area51/log/branches/plasma5

Test Plan

Builds fine in poudriere (120amd64). I haven't tested yet any other architecture
with these patches, but the ones from [2] build fine on all FreeBSD from 9 to 12.

The ports as they are have been used for more than two years in the testing
repo. And are actively used by myself.

[rakuco]

Mk/Uses/kde.mk

25

Small nitpick: you could keep this list alphabetically sorted.

27

I think it makes sense to keep this line.

38–39

Or least make sure you say "KDE4 and KDE Frameworks 5".

108

The bit about the exceptions looks like a regression compared to the diff landing the KDE_CATEGORY change.

216

Minor nitpick: it's good to keep the list sorted.

369

I guess it makes sense to set apidox_TYPE=run.

[rakuco]

In D8329#173341, @mat wrote:

Mmm, ok, so, what have other OS done with it ?

Fedora uses the "kf5-" prefix in their packages, Debian and Ubuntu use "libkf5" and ArchLinux and OpenSUSE just don't use any prefix (the packages are called "attica", "kcrash" etc).

[adridg]

In D8329#173341, @mat wrote:

Mmm, ok, so, what have other OS done with it ?

Having it move from kde4 to kf5 is just confusing.

The upstream made a decision to release, instead of one big "KDE", three separate software products: KDE Frameworks, KDE Plasma, and KDE Applications. These is no one big "KDE" release anymore -- except, as tcberner@ has pointed out, we'll create an x11/kde5 port to do the right things for people who expect an upgrade path from kde4 to kde-a-bigger-number.

So this is the first third of all that.

KDE Frameworks are small, lightweight libraries on top of Qt, providing a variety of .. things that are missing in Qt itself. They're also dependencies for non-KDE desktops like LxQt, and for various applications you might consider "Qt only".

[adridg]

Mk/Uses/kde.mk

6

It's also not accurate any more: only USES=kde:ARGS works, and it must be one of the "Valid ARGS" listed below (i.e. 4, 5).

25

USE_KDE right now is only the KDE4/KF5 components -- there's no Plasma 5 or other components possible (that comes in a follow-on update).

108

Yes, that was my fault in area51, missed a merge from ports while merging down from plasma5/ branch. Same applies to line 109 (below), regression from previous CPE_VERSION setting.

216

Question about (to me) inconsistent use of continuation lines: here, upstream area51 had all the components listed one per line; in this patch, they're bunched up onto one line. Below, at _USE_FRAMEWORKS_ALL, upstream had the list of variable-tiers bunched together; in this patch, they're split one-per-line, with continuations. Is there a preferred style?

[tcberner]

Address most of the issues raised by rakuco@.

[tcberner]

mark stuff done.

Mk/Uses/kde.mk

216

The standard in kde.mk is that the component lists are wrapped, with multiples on one line, thats why I changed this back -- also it is more readable, because you see all the components on one screen and do not have to scroll 400 times :)

For the gather list _USE_FRAMEWORKS_ALL below it seemed however more readable with one on each line :)

424

I think ecm should be build/run. All the cmake files installed by KF5 require it to work properly.

So without ecm present they are all broken.

Or was this wrt to doctools?

x11-toolkits/kirigami/Makefile

13

This is the description of the repo upstream: https://quickgit.kde.org/?p=kirigami.git

[tcberner]

Adress some more issues

• Fix FOO=YES -> FOO=yes
• Fix Created by:
• Use Yuri's extra-cmake-modules Makefile (though I'm not a fan of all these options).
• Fix typo in the gpgme-qt5 dependency of sysutils/kf5-kwallet
• Remove sysutils/kf5-baloo/files/patch-src_file_timeestimator.cpp -- upstream commit fixes this
• Remove x11/kf5-kinit/files/patch-src__kdeinit__CMakeLists.txt -- does no longer fail

[tcberner]

sysutils/kf5-baloo/files/patch-src_file_timeestimator.cpp

7 ↗

(On Diff #21629)

It has been commited in [1] and can therfore be dropped.

[1] https://quickgit.kde.org/?p=baloo.git&a=commit&h=82b93d175184d4991d5055eccb968c9a137505e2

x11/kf5-kinit/files/patch-src__kdeinit__CMakeLists.txt

1 ↗

(On Diff #21629)

This is indeed no longer needed. If I had to guess the issue was that it didn't find the X11-headers at some point as -I/usr/local/include was not passed properly.

But for now. Drop it.

[tcberner]

Forgot:

• get rid of sysutils/kf5-bluez-qt -- it snuck in by carelessness :)

[tcberner]

Get rid of the CXXFLAGS=-fno-use-cxa-atexit. With or without kactivitymanagerd
sometimes crashes at exit [1].

[1] The flag was originally from x11/kactivitymanagerd of KDE 4:

# Workaround to keep kactivitymanagerd from crashing:
# http://lists.freebsd.org/pipermail/freebsd-current/2012-May/033972.html
.if ${OPSYS} == FreeBSD && ${OSVERSION} > 1000000
CXXFLAGS+=      -fno-use-cxa-atexit
.endif

[rakuco]

I've landed part of the cosmetic changes to Uses/kde.mk in rP424901 and rP424903.

I think the only bigger thing that needs to be improved is the use of your FindLibinotify.cmake: how about installing it with extra-cmake-modules so you don't need to copy it to the ports that need it? I'm also hoping/assuming you're already working on upstreaming it.

devel/kf5-extra-cmake-modules/Makefile

9

CMake, not Cmake. In fact, I don't think it's reeeeally necessary to change COMMENT here.

51

Are you sure this is needed? It was not set before, and the port still installed fine.

54

These sed calls always smell bad... Looking at ECMQueryQmake.cmake, you can just set QMAKE_EXECUTABLE if really necessary.

devel/kf5-kapidox/Makefile

18

Same thing: is this necessary?

devel/kf5-kcoreaddons/files/patch-src_lib_io_kdirwatch.cpp

9

What if you replace this with defined(HAVE_SYS_INOTIFY_H)? Plus, what's the upstreaming status of this patch?

devel/kf5-kfilemetadata/Makefile

12

Minor nitpick: the list should be sorted.

25

Minor nitpick: extra empty line.

devel/kf5-kidletime/pkg-plist

16

?

devel/kf5-kitemmodels/Makefile

14

Minor nitpick: there's trailing whitespace here.

devel/kf5-solid/files/patch-CMakeLists.txt

8

Is there a reason why this is being done here and not to the other ports?

sysutils/kf5-baloo/Makefile

27

USES=pathfix?

x11/kf5-frameworks/Makefile

13

Not sure it makes sense to set LICENSE with a metaport.

x11/kf5-plasma-framework/Makefile

12

USE_XORG= xrandr?

[tcberner]

Adress some more of rakuco@ points.

[tcberner]

devel/kf5-extra-cmake-modules/Makefile

51

===>   Generating temporary packing list
make[1]: don't know how to make install/strip. Stop

make[1]: stopped in /wrkdirs/usr/ports/devel/kf5-extra-cmake-modules/work/.build
*** Error code 2

54

I think the default value for qmake in the file should be a valid value. That's why this sed call is there.

Are you happier with the new patch?

devel/kf5-kapidox/Makefile

18

===>   Generating temporary packing list
make[1]: don't know how to make install/strip. Stop

make[1]: stopped in /wrkdirs/usr/ports/devel/kf5-kapidox/work/.build
*** Error code 2

devel/kf5-kidletime/pkg-plist

16

indeed...

This is something I forgot about =). -- The port needs USE_XORG+=xscrnsaver as a dependency so that this file gets generated.
Fixed.

devel/kf5-solid/files/patch-CMakeLists.txt

8

AFAIR, because it ignores the value of cmake's BUILD_TESTING variable.
Normally it should be

if (BUILD_TESTING)
add_subdirectory(autotests)
endif()

in the CMakeLists.txt

But you're right. In the other ports that do not check for BUILD_TESTING either I simply gave in and added USE_QT5+=testlib.

sysutils/kf5-baloo/Makefile

27

Yup. I didn't change it in plasma5 yet, because the quarterly branche's pathfix.mk didn't yet know about it.

[tcberner]

No, I have not yet done any work to upstream FindLibinotify.cmake.

I'll do that soonish...

[adridg]

Mk/Uses/kde.mk

216

OK, I accept that it can be consistent in a way that I wouldn't do, you can mark these as done.

424

On the principle that installing library Foo on FreeBSD also gives you the stuff you need to develop against Foo (compare Linux distro's insistence on separate -devel packages), then ecm is build & runtime dependency, since you can't use the CMake files installed by Foo without ecm (although anything using Foo would probably also build-depend on ecm anyway ..). I'd suggest leaving this as-is.

chinese/fcitx/Makefile

24

This change isn't directly related to import-kf5, it's a cleanup enabled by that import. Does that belong in this review? (I just don't know what the policy is)

45

It's kind of weird to have a "kde:5" dependency in a port that doesn't even have a Qt5 option, and which defaults to GTK2 and Qt4.

[tcberner]

I have an upstream review pending for FindLibinotify.cmake in devel/kf5-extra-cmake modules.
I will update this diff once that is accepted... hopefully soonish.

[tcberner]

respond to Adriaan.

chinese/fcitx/Makefile

24

Well, yes and no ^^.

I had to change this ports Makefile anyway, as devel/extra-cmake-modules -> devel/kf5-extra-cmake-modules.
So I thought, I could do it right, and just use USES=kde:5, USE_KDE=ecm while here.

45

USES=kde:5 does not add any dependency on kde-sepcific-bits. It just sucks in the stuff from kde.mk and enables us to use USE_KDE=ecm, which is more robust than to depend on a given file of devel/kf5-extra-cmake-modules which might be dropped in three releases time (how ever unlikely that is).
[But I grant you, it looks weird].

[tcberner]

Add FindLibinotify via devel/kf5-extra-cmake-modules, and teach Mk/Scripts/qa.sh
about the kf5-components.

[rakuco]

devel/kf5-extra-cmake-modules/files/patch-git_add_FindLibinotify.cmake

1 ↗

(On Diff #22170)

While this does not land it's a good idea to provide a link to the reviewboard request.

devel/kf5-extra-cmake-modules/files/patch-modules_ECMQueryQmake.cmake

3 ↗

(On Diff #22170)

Still missing a - at the beginning of the line.

3 ↗

(On Diff #21793)

I think you're missing a - at the beginning of the line.

devel/kf5-kapidox/Makefile

5

I think this port needs both a build- and a run-time dependency on Python.

devel/kf5-solid/files/patch-CMakeLists.txt

8

So should this patch be removed or not?

[tcberner]

• Add reviewboard url to FindLibinotify.cmake
• Fixup the patch line missing a '-', how that happend, I have no clue...
• Remove the patch in devel/kf5-solid

[tcberner]

mark stuff done

Btw, now that frameworks 5.28.0 is out.. should I update this diff?

devel/kf5-kapidox/Makefile

5

From Mk/Uses/python.mk:

32 # If build, run and test are omitted, Python will be added as BUILD_DEPENDS,
33 # RUN_DEPENDS and TEST_DEPENDS. PYTHON_NO_DEPENDS can be set to not add any
34 # dependencies.

So this is already the case, no?

devel/kf5-solid/files/patch-CMakeLists.txt

8

Sorry, this somehow got lost. Now removed, and replaced by USE_QT5+=testlib .

[rakuco]

Btw, now that frameworks 5.28.0 is out.. should I update this diff?

Up to you. I'm fine with both landing this diff as-is or, if 5.28 has already been tested and known to work, updating the patch (I'm assuming there are no changes other than version bumps).

devel/kf5-kapidox/Makefile

5

Ah, sorry, I didn't see the USES=python bit in the Makefile.