why kdelibs?

[Alexander Neundorf]

On Saturday 30 October 2010, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > 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.
>
> I think the big difference is that KDE4 introduced many new and different
> technologies that needed to be ported to (akonadi, plasma for example),
> whereas reorganizing kdelibs involves shuffling things around and renaming
> libraries. So you'de use, for example, KPlatform::Locale instead of KLocale
> (which uses KConfig, KStandardDirs etc), whereas Gregory would use
> KLibs::Locale (which uses possibly self implemented or contributed
> interfaces which use QSettings, etc).
>
> Until we try some things out we won't know what the impact on kde apps
> would be.
>
> > Maybe first move everything into kdelibs (kdeuspport, kdepimlibs), and
> > then cut it into parts?
>
> Yes, that's exactly what I wrote on the wiki page.

I didn't see the link to the wiki page yesterday, so I didn't know you wrote 
that page.
I agree with what you wrote there, except that I would put more importance on 
keeping source compatiblity.
E.g. instead of "Remove K-Classes where Q-Classes are available and 
sufficient" I would prefer something like "Move K-Classes where Q-Classes are 
available and sufficient into a kde4support library".

So, in general I fully support this, and I will care for the work necessary in 
the buildsystem. A sprint might be necessary if we really decide we want to 
do this.

> >> 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).
>
> I'm starting to not understand what you mean. Or else you didn't understand
> what I meant.

Probably a misunderstanding on both sides.

> If a software vendor creates an application to run on particular hardware,
> they must build it, and package it on the hardware together with any
> dependencies. Then they give the hardware with the software on to whoever
> pays them to do it. Making that building and packaging happen is the part
> that must happen anyway. The software vendor does not rely on the user or
> distro to make the dependencies available and configured properly. They do
> that themselves.

Yes.

> If that software requires a set of classes for asynchronous job execution,
> itemviews, handling of Mime documents or IMAP communication, and all those
> things exist in kde libraries (where they are tied to each other, other
> unrelated libraries, and the platform), then it should be possible to use
> those kde libraries without a lot of hassle, 

Yes, it should.

> because they are mostly 
> Qt-only libraries without any wierd non-windows deps.
>
> I'm talking about a reorganized kdelibs (Tiered) where every library does
> not depend on every dependency of every other library. In that context I
> don't understand your response. Which non-windows dependencies are you
> talking about?

This is an excerpt from FindPackageLog.txt of kdelibs (which cmake creates 
when you use cmake >= 2.8.3):
-- Found the following packages:
X11
Threads
Qt4
Automoc4
Perl 
Phonon (required version >= 4.3.80)
ZLIB
Strigi 
LibAttica
BZip2 
LibLZMA
OpenSSL 
Libintl 
OpenGL 
Soprano (required version >= 2.5.60) 
SharedDesktopOntologies (required version >= 0.5)
DBusMenuQt 
ACL
FAM 
PCRE 
Flex 
LibXslt
LibXml2
DocBookXML
DocBookXSL
SharedMimeInfo
ASPELL
JPEG
GIF
PNG
OpenEXR 
-- Did not find the following packages:
KDE4Internal
PkgConfig
QCA2 
Grantlee 
HUpnp
GSSAPI 
HSPELL
ENCHANT
Jasper
Avahi 
DNSSD 


When writing an Open Source application, that's not a big problem.
But at work we want to ship our executable in binary form, and we want to keep 
our dependencies to a minimum, and we also want a small number of 
dependencies so we have the chance to understand a big percentage of the 
software components we use.
Now the list for kdelibs contains 42 dependencies, not all are REQUIRED 
(...this should be recorded in FindPackageLog.txt, will do that...).
Some are trivial (bzip2, zlib, X11, JPEG, PNG, some more).
And some are unnecessary for us at work (DocBookXML, SharedMimeInfo, 
SharedDesktopOntologies), but wouldn't be a big hassle, and some are things 
which are also unnecessary for us at work, and which we really would want to 
avoid (Soprano, Strigi).
Finding out which parts of kdelibs need what or whether the library I'm 
interested in depends on a kdelibs library which uses some of these listed 
libraries, even if only in a rare corner case feature we are not interested 
in (at work), is work which consumes time (...and money).

And I think this is actually exactly the issue you are also talking about and 
where we'd like to improve.

> > 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.
>
> You're the expert on this, not me. I know very little about the kde build
> system. However, I imagined that the kind of platform level build system
> integration you mention here (so that kde application developers don't have
> to care too much) could be implemented 'above' the libraries, not below
> them.

Hmm, below you can see a hypothetical example of what is more or less 
necessary.

Right now, for a lib kfoo being part of kdelibs, a CMakeLists.txt can look 
something like this:

if(HAVE_BAR_H)
  set(scrs bar.cpp)
endif()

kde4_add_library(kfoo ${srcs})

target_link_libraries(kfoo kdecore kdeui ${BAR_LIBRARIES} )



To be able to be built independently, it must be something like the following:



if(NOT kdelibs_SOURCE_DIR)
   # must find only parts of kdelibs:
   find_package(KDE4 REQUIRED COMPONENTS kdecore kdeui)

   include_directories(${KDE4_INCLUDES})

   include(KDE4Defaults)

   include(CheckIncludeFiles)
   check_include_files(bar.h HAVE_BAR_H)
   configure_file(myconfig.h.in config.h)
   
endif()

if(HAVE_BAR_H)
  set(scrs bar.cpp)
endif()

kde4_add_library(kfoo ${srcs})

target_link_libraries(kfoo ${KDE4_KDECORELIBS} ${KDE4_KDEUI_LIBS}
                           ${BAR_LIBRARIES} )


Alex