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