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 _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
