On 8/10/07, Kyle Heath <[EMAIL PROTECTED]> wrote: > I would like to use cmake to build a set of single target projects > (each project generates either one library or one executable). I > understand how to handle dependencies on external packages with the > <foo>Find.cmake scripts, but I don't know how to deal with internal > CMake built packages. There is some kind of magic with a > <name>Config.cmake that I don't understand. > > Here's a little high-level "use case" scenario to illustrate what I want to > do: > > My executable project HelloWorld uses package "MyLibA" directly. In > the CMakeLists.txt for HelloWorld I want to simply do something like: > SET(requiredPackages MyLibA) > > My static library project "MyLibA" uses package "MyLibB" directly. In > the CMakeLists.txt for MyLibA I want to simply do something like: > SET(requiredPackages MyLibB) > > I want cmake to follow the package dependency chain so that my > HelloWorld executable project gets all the library file names and > include directories it needs to compile and link. If I change a file > in library B and rebuild my executable HelloWorld, I want it to detect > that it needs to rebuild package "MyLibB" and "MyLibA" and relink my > executable. > > I'd also like to handle different build types. If I build my project > in debug mode, i want it to use the debug versions of all the packages > it depends on (and not rebuild "release" versions that won't be used). > > Is cmake powerful enough to do this (and make it simple to use)? > > Does the "Mastering CMake" book explain how to do these basic sort of things?
If I understand your questions, the answers are yes, and yes: CMake does everything you mention, and generally does it very well. The book is a good read, although this email list is a very helpful supplement. _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake