Building multiple source modules

[Allan Sandfeld Jensen]

Hello

I have recently been worried about the increasing number of modules KDE is 
being divided in. Having to checkout, configure and build a huge amount of 
individual modules seems to greatly increase the time it takes for developers 
to build new test versions of KDE. This is especially true if you make changes 
to basic libraries and want a full KDE installation rebased on the modified 
libraries.

To try to solve this I have experimented with building multiple modules in a 
single CMake run. So far I've just used the old SVN modules, but the same 
principle should be even more useful for the more fine-grained Git modules.

The idea is to allow developers to create new top CMakeLists.txt files that 
looks something like this:

cmake_minimum_required(VERSION 2.6)
add_subdirectory( kdeutils )
add_subdirectory( kdesdk )
add_subdirectory( kdemultimedia )
add_subdirectory( kdegraphics )
add_subdirectory( kdenetwork )

Such a simple cmake file can quickly be made by anyone depending on what 
modules they need to build in one go.

There is one problem though: Adding a new top dir changes the CMAKE_SOURCE_DIR 
and CMAKE_BINARY_DIR variables. CMake however has better project relative 
variables called PROJECT_SOURCE_DIR, PROJECT_BINARY_DIR, plus the specific 
%project%_SOURCE_DIR and %project%_BINARY_DIR. By replace all top dir relative 
variables with appropiate project relative dirs, the source modules can easily 
be nested in new super modules, and thus be build and configured collectively. 

Making this change is not hard, and I have attached the patches necessary to 
build kdeutils, kdesdk, kdemultimedia, kdegraphics and kdenetwork in this way. 
The patched source of course still allows building one module at a time, and 
in several instances these more specific variables actually makes it easier to 
build sub-parts of modules individually.

I would like permission to apply the patches, and would like to suggest that 
we require all KDE CMakeLists.txt to use project-relative paths in the future. 
I think for instance it could be an excelent opportunity to make these minor 
changes while we are already splitting the modules.

What do you think?

Best regards
`Allan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-buildsystem/attachments/20110119/3bc1515e/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdesdk.diff
Type: text/x-patch
Size: 3343 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20110119/3bc1515e/attachment-0005.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdeutils.diff
Type: text/x-patch
Size: 1817 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20110119/3bc1515e/attachment-0006.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdemultimedia.diff
Type: text/x-patch
Size: 4236 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20110119/3bc1515e/attachment-0007.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdegraphics.diff
Type: text/x-patch
Size: 3440 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20110119/3bc1515e/attachment-0008.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdenetwork.diff
Type: text/x-patch
Size: 9560 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20110119/3bc1515e/attachment-0009.diff