Building multiple source modules

Allan Sandfeld Jensen kde at carewolf.com
Wed Jan 19 20:29:46 CET 2011


On Wednesday 19 January 2011, Alexander Neundorf wrote:
> Hmm.
> This is similar to what we do/did in kdesupport, and I did not really like
> it. One problem is what you mentioned, and there is at least one other
> issue/problem.
> In such a setup, all those projects share a common CMakeCache.txt.
> The behaviour of cache- and not-cache variables with the same name is not
> exactly the most obvious thing in cmake (see e.g.
> http://public.kitware.com/Bug/view.php?id=9008).
> I don't remember what it was exactly, but there were cases where things
> didn't do what the developer expected because the variable he used was
> already set in the cache by another (sibling) project.
> 
> Additionally, they will also share the GLOBAL properties then.
> 
> They will share the scope for target names, target names should/must be
> project-wide unique (we disabled this check by setting a cmake policy, so
> cmake doesn't complain...)
> 
> Having kdelibs or another libs-module as part of such a build will not work
> out-of-the-box, since the Find<TheRespectiveLibModule>.cmake will not find
> it, since the lib module has not yet been installed.
> 
This is why I only tried it on modules that share the same position in the 
build order. This is currently only useful for extragear-like applications, 
but not for building kdesupport parts, kdelibs, kdepimlibs and kdebase in the 
right order.


> 
> Do you know the ExternalProject feature in cmake ?
> I think this was introduced with cmake 2.8.0:
> http://www.kitware.com/products/html/BuildingExternalProjectsWithCMake2.8.h
> tml
> 
> With this you can download, patch, build and install complete projects
> independent from each other within one cmake project.
> 
<snip>
> Feel like giving this a try ?
> 
Yes, I will definately give that a try as soon as possible.

> I would prefer to use the specific %project%_SOURCE/BINARY_DIR variables
> everywhere consistently, which you have done partly, or was there a reason
> to use PROJECT_SOURCE/BINARY_DIR in the other cases ?
>
Only to make it easier to copy/paste, but that is of course both a curse and a 
blessing. I switched halfway through my conversion, but reverted it to make 
the posted patches more consistant. 


`Allan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-buildsystem/attachments/20110119/a401b4e3/attachment.htm 


More information about the Kde-buildsystem mailing list