frameworks build issues

[Stephen Kelly]

Jeremy Whiting wrote:

> Hello all,
> 
> I took another crack at the kcolorscheme migration in frameworks
> branch yesterday, and got it to not depend on KGlobalSettings any
> longer.  Unfortunately I still get warnings when I run cmake like
> this:

There are two issues.

For one of them I filed a bug against cmake:

http://public.kitware.com/Bug/view.php?id=12588

The second issue is that libkgui depends on kdecore, which is not a 
'framework'. It's premature for libkgui to exist if it depends on kdecore. 
The things that it depends on in kdecore would have to be split out.

> Should we be using separate branches to work on stuff like this and
> merge them into frameworks when they build?

I think that would just complicate things. I think what we actually need is 
more structured efforts. The people who want libkgui to exist need to do 
work on the lower levels before creating it. The things libkgui depends on 
need to be close to their final state (in terms of build and dependencies) 
before libkgui can exist. This is where we need concrete goals which will 
hopefully be hammered out in the IRC meeting.

The most important thing we need right now is modularity, which we can do 
better to enforce in the buildsystem. It should be possible to build things 
standalone. Currently for example solid and kcoreaddons can not be built 
standalone because they get config.h from the top level 'kdelibs', along 
with their dependencies, and they use cmake macros that they should not 
(macro_bool_to_01() is replaced by #cmakedefine01 for example), so 
libkcoreaddons is not 'done' or 'ready', however you want to call it.

To be 'done' it would need to create its own config file with the stuff that 
it needs, find its dependencies by using Find packages from extra-cmake-
modules, port away from the no-longer-used cmake macros such as 
macro_bool_to_01 and macro_optional_find_package. This is what 'done' looks 
like and is what we need to aim for for each framework.

We can enforce this by creating a 'done' folder, and calling 
add_subdirectory(done) in kdelibs.git/CMakeLists.txt as early as possible. 
At least *before* the call to find_package(KDE4Internal REQUIRED).

This will mean that kdelibs.git/cmake/modules will not be used anymore etc, 
and mean that for a framework to work in the 'done' folder, its cmake stuff 
needs to come from extra-cmake-modules.

I can create that folder soon and start moving things in there (at least 
itemmodels is 'done' already).

Any objections?

Thanks,

Steve.