Building multiple source modules

[Alexander Neundorf]

On Wednesday 19 January 2011, Allan Sandfeld Jensen wrote:
> 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.

PROJECT_SOURCE_DIR refers to the "closest" project() call, not necessarily to 
the project() call in the toplevel directory. I.e. if there is a project() 
call in toplevel/subdir/CMakeLists.txt, PROJECT_SOURCE_DIR will be 
toplevel/subdir/ in toplevel/subdir/CMakeLists.txt, and not toplevel/.

I think being explicit is better here.

Alex