<div dir="ltr"><div>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:<br>

<br></div><div style="margin-left:40px">project(blah)<br><br></div><div style="margin-left:40px">add_subdirectory(foo)<br></div><div style="margin-left:40px">add_subdirectory(...)<br>...<br>add_subdirectory(bar)<br></div>

<div><br></div><div>and in the CMakeLists.txt in the foo directory:<br><br></div><div style="margin-left:40px">include_directories(${bar_SOURCE_DIR})<br></div><div><br></div><div>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}.<br>

<br></div><div>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 ?<br>

<br></div><div><div></div><div>--<br></div>Glenn<br><br>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 :-)<br>

</div><br></div>