On 23/08/07, Alexander Neundorf <[EMAIL PROTECTED]> wrote: > On Thursday 23 August 2007 07:34, Simon wrote: > > To quote http://www.cmake.org/HTML/WritingCMakeLists.html : > > > > << begin quote >> > > CMake works recursively, descending from the current directory into > > any subdirectories listed in the SUBDIRS command. The command SET is > > used for setting a variable, in this case to a list of source files. > > > > <<snip>> > > > > INCLUDE_DIRECTORIES() > > LINK_DIRECTORIES() > > LINK_LIBRARIES() > > TARGET_LINK_LIBRARIES() > > > > These commands define directories and libraries used to compile source > > code and build executables. An important feature of the commands > > listed above is that are inherited by any subdirectories. That is, as > > CMake descends through a directory hierarchy (defined by SUBDIRS()) > > these commands are expanded each time a definition for a command is > > encountered. > > << end quote >> > > Oh, it still mentions SUBDIRS(). > You should use ADD_SUBDIRECTORY() instead.
Yes, a number of the static web pages still mention the old commands, but I've got that figured out. > > > > If I add an additional include path using INCLUDE_DIRECTORIES in a > > CMakeLists.txt buried in a subdirectory, when CMake is finished > > processing in that subdirectory and comes back up to the parent > > CMakeLists.txt, is the additional include path still in effect? > > No. Cool, so you're saying that I will get the behaviour I want? Where, changes to the include path at a subdirectory level will be discarded when the the parser comes back up to the parent? I've downloaded the vispack project as a reference for how to set up a modular CMake system, any other good references? KDE4 may be a bit overkill though, as I'm working on Windows (for the moment). > > Bye > Alex Thanks for the help! Simon _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
