why kdelibs?

[Alexander Neundorf]

On Saturday 30 October 2010, Stephen Kelly wrote:
> Replying to John and Kevin here.
>
> John Layt wrote:
> > Some excellent points, and it makes clear the sort of areas we need to be
> > working on.  Currently choosing to use kdelibs or any other KDE library
> > just as an extra Qt module usually means more pain, not less, which
> > really should be our selling point.
> >
> > Do we have a wiki page were 'what can be fixed now' and 'what needs
> > fixing in
> > KDE5' has been/can be written down?  Perhaps a version of
> > http://techbase.kde.org/Projects/Mobile/PlatformModifications but with a
> > little more detail?
>
> I have wanted to write this down in words for some time, so here it is:
>
> http://techbase.kde.org/index.php?title=Projects/KDELibsModifications
>
> > While a lot of the dependency fixing would break BC and so can't be done
> > in the KDE4 SC, I suspect a lot of 3rd parties would actually ship their
> > own copy
> > of of what they use anyway, rather than using shared libraries?  In which
> > case we can do compile time switches for them to just get what they need
> > without
> > all the other stuff?  Of course there would be a lot of work providing
> > the alternative paths, but it would be in preparation for KDE5 and thus
> > less work to do then?
>
> I would say make the split stuff available in KDE4 as KDE5Support. Then we
> declare KDE5 when the apps are ported and remove the KDE4 stuff. It's an
> option at least.

I think BC is less important that SC.
If a KDE5 would just require a recompile, and maybe some changes in the cmake 
scripts (like additional find_package(SomeKLibrary)), this shouldn't be a too 
big problem for KDE.
If it would mean people have to rewrite their apps, as they just did for KDE4, 
it might be deadly for KDE I'm afraid.

...
> > For those libraries like KIMAP and the itemview stuff that don't really
> > need kdecore/kdelibs stuff at all perhaps kdesupport is the right place
> > for them? Perhaps the 'K' name is also an issue, if they don't need K
> > stuff, then just
> > call them QSomething or a funky non-K name?  From a promo point of view,
> > we could then advertise libraries as being 'By KDE', 'Using the KDE
> > Platform', and 'For the KDE Desktop'.
>
> I counter-proposed merging kdesupport into kdelibs. I think in some cases,
> libraries went into kdesupport because they were functional, rather than
> platformy, so their authors didn't see any sense in adding the platformy
> dependency and baggage. That happened in the case of Grantlee and others
> too I'm sure. If something like Tier 1 existed when I started that, I would
> have put it there.

Maybe first move everything into kdelibs (kdeuspport, kdepimlibs), and then 
cut it into parts?

> Having those things in a group we call kdelibs makes the release, promo and
> i18n machinery available to them as well as actually being part of the KDE
> community produce.
>
> > The other issue is platform portability, stick with Qt and you know it
> > works on every platform with no extra effort, even if the tools fall
> > short in some areas.  Use kdelibs and you will have problems on Win and
> > Mac trying to decide
> > how to package and distribute.  Work is ongoing on Win to make it happen,
> > but Mac appears to have stalled somewhat?
>
> It seems many packaging and distribution problems either fall away, because
> the author controls both, not a distro and not the user, or fall away
> because they exist and must be solved anyway if Gregory-the-Qt-developer or
> ACME Qt-using software vendor is creating software.

But if the developer is the one who "must solve it anyway", this may be just 
the reason to avoid doing it and staying with Qt-only (since it will avoid 
spending a lot of time of building dependencies on Windows which are not 
fully and officially supported on Windows).

> > Of course, once the splitting work is done, and it's easily portable,
> > then eternal vigilance is needed to make sure it stays that way, which
> > probably means more stringent rules around kdelibs.
>
> Right. But if split well, it might always be obvious where things belong.

Yes, maybe. Hopefully.

> Kevin Ottens wrote:
> > Note though that there's likely two things to keep in mind:
> >
> > a) We have to be careful to not split our libraries too much, if they
> > become too small and too numerous we'll very likely pay it in
> > application/workspace startup time on some platforms (definitely need to
> > be carefully benchmarked and so on, there's a trade-off to find).
>
> To some extent I think this is already happening with kdesupport and the
> number random git repos growing.
>
> As Jaime notes though it might be possible to build the libraries together
> if CMake'd from kdelibs/ and also make it possible to cd kjob && cmake. I'm
> not certain it's possible or sensible. Just another option.

It is possible, but it needs work.
A lot of things are done as they are done in KDE so that individual KDE 
developers don't have to care too much about the build system, and to avoid 
duplication. The most obvious thing are the installed cmake find-modules from 
kdelibs.
Feature tests are done in the toplevel CMakeLists.txt and a config.h is 
created there, so all libraries which need these tests have the results 
available. find_package() is done partly in the toplevel files, so libraries 
needing those packages don't have to find_package() themselves, which also 
saves a bit of cmake-configure time.
When we want to be able to do cd kjob && cmake, kjob needs to have all the 
necessary tests etc. in its own directory. This needs work from the library 
maintainer, i.e. from all library maintainers.
When their feature tests (HAVE_SOME_HEADER_H etc.) use the same names for the 
result variables, cmake doesn't run the test again, but just returns the 
existing result from the previously already executed test.
So, there will be duplication, and cmake-time will become somewhat (a bit ? a 
lot ? I don't know) bigger, and there will be complaints about that.

Also, each of those libs then needs to handle the two cases (built as part of 
kdelibs or built independently) themselves, most obvious issue is that if it 
is built independently, it needs to search for Qt itself.

So, it is possible, without any conceptual problems, it's just a big piece of 
work, which must be done (or at least maintained) by the individual library 
developers.

But I would like that approach nevertheless.

Alex