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.

>>
>> 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.

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.

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, 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?

> 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.

All the best,

Steve.