Re: Question for fellow retro-computers : building kdelibs4 without nepomuk?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Friday May 24 2024 04:37:39 Duncan wrote:

>As I recall, for most of kde4, even with semantic-desktop disabled (to the 
>degree possible), while the backends (raptor/redland/etc) weren't required 
>in that case, the frontend libs were still mandatory build-time and run-
>time required.

Do you happen to have a pointer to the most recent version of the patch you mentioned?
AFAICT, the nepomuk library isn't built at all when the raptor/redland soprano backends aren't installed. I had a quick look at what components actually need it (rather than link to it out of habit); possibly kactivities. Which is one of those IDE components that are probably devoid of interest except in a full DE.

Soprano itself builds just fine so there's no problem with having the library present.

The good news is that in the meantime we've identified that the problem is actually a regression in raptor 2.0.16 that's being addressed as we speak, and that simply downgrading to 2.0.15 allows us to continue the revival adventure.

>Tho I suppose the CI would be current-targeted and if you're on Intel-Mac 
>hardware,

Apple haven't yet ditched all support for the Intel architecture (though surely will sooner rather than later given their track record in dropping support for older models). The problem is that this entire effort focusses on models even older than my own 2011 Mac. Many of those don't even run a recent Qt5 version (while Qt 5.15 still supports Win7 from what I hear, which is also older than my Mac and definitely older than the latest OS X it can run).

One of the big hurdles with KF5 was that Qt5 introduced their version of KStandardPaths, and gave it a "proper Mac-native implementation". KDE migrated to that class, but never bothered to update their build system. So while the code is perfectly capable to find its runtime resources where Qt says they should be, the build system installs them to the places where the XDG standard says they should go. Except for a handful of applications were, like Kate. KDE have also been pretty strict about "Macs don't have dbus" (they can, it's even an officially supported target) or "Macs/PCs shouldn't have KCMs + systemsettings, widget themes or a platform plugin". One of the more OCD-pedantic Plasma developers even once said that he felt like breaking all possibilities to build "his" code on the "wrong" platform, "just because he could".
In short: I spent countless hours patching things including QStandardPaths and other Qt bits just to get a proper UI experience and full-featured KDE applications. Only to find myself blocked at Qt 5.9 which already doesn't officially support the OS version I'm running.

In short: starting this all over for [QK]*6 ... no thanks.

I never even bothered with KDEPim5, actually. Partly because even test-driving it means you can't go back to KDEPim4, partly because another OCD-pedantic dev decided it'd use QtWebEngine throughout, which is complete overkill for just displaying HTML email.

R.



[Index of Archives]     [Trinity (TDE) Desktop Users]     [Fedora KDE]     [Fedora Desktop]     [Linux Kernel]     [Gimp]     [GIMP for Windows]     [Gnome]     [Yosemite Hiking]
  Powered by Linux