[CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?

[Glenn Coombs]

I'm using cmake version 2.8.12.1 and have just encountered an issue with my
cmake setup where I was using the [Project name]_SOURCE_DIR variable in an
include_directories command and it was being ignored.  In my top level
CMakeLists.txt I had:

project(blah)

add_subdirectory(foo)
add_subdirectory(...)
...
add_subdirectory(bar)

and in the CMakeLists.txt in the foo directory:

include_directories(${bar_SOURCE_DIR})

The project failed to build because the foo project couldn't find header
files located in the bar project source directory.  The fix was to move the
add_subdirectory(bar) before the add_subdirectory(foo) command.  The
interesting thing is that this setup only caused an error when doing a
clean build from scratch.  It looks like it only fails after a clean start
and a single run of the cmake generator.  If you run cmake-gui and
configure more than once, as you may well do if you need to set some
options, then it appears to get the correct value for ${bar_SOURCE_DIR}.

Are the [Project name]_SOURCE_DIR variables being automatically stored in
the cmake cache, as that would explain what I am seeing ?  I would expect
the above scenario to consistently fail every time due to the missing
header files.  Having it only fail the first time and then work after
subsequent configure/generate steps is confusing.  Is this a bug, or are
there occasions when this is desirable behaviour ?

--
Glenn

P.S.  In an ideal world I'd like to see the expansion of the [Project
name]_SOURCE_DIR variables be deferred until after all the CMakeLists.txt
files have been read in so that the order doesn't matter, but I'm guessing
that isn't going to happen :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20140423/514bcc96/attachment.html>