frameworks build issues

[Stephen Kelly]

Alexander Neundorf wrote:
>> 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.
> 
> Yes. And this is also by far not "done" yet.

Yes, there is still a lot of groundwork/foundational work to be done. The 
problem is that we do already have people building various parts of the 
upstairs of the house before any parts of the foundation or the ground floor 
are ready for that. 

I think that needs to be discouraged and encourage focussing on the 
foundational work.

There's still plenty that can be done without being blocked by the extra-
cmake-modules/pkg-config efforts. Grepping for macro_bool_to_01 and other 
macros and replacing their use, finding out what a library actually needs 
from kdelibs.git/config.h and creating a module-specific one, replacing 
KIcon with QIcon in APIs etc. There's plenty more. 

People who want to contribute to the frameworks effort aren't going to see 
them until they try to create the next libkgui and realize that the top 
level CMakeLists prevents them from depending on kdecore, and then 
investigating what needs to be done about that. We could try to make a list 
of tasks on the wiki, but new people would still have to become self-driven 
very quickly, so we need to make sure the opportunities for that appear 
early.

Thanks,

Steve.