[CMake] Handling of include directories when recursing sub-directories

[Simon]

On 23/08/07, Alexander Neundorf <a.neundorf-work at gmx.net> 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