<div dir="ltr">Ugh !  It gets messier.  I'm beginning to understand why it is the way it is.  The cmake developers have probably already been round this loop and decided it wasn't worth the effort :-)<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On 1 May 2014 19:41, Nils Gladitz <span dir="ltr"><<a href="mailto:nilsgladitz@gmail.com" target="_blank">nilsgladitz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On 01.05.2014 20:38, Glenn Coombs wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Okay, I think I understand what you're saying.  Variables set in a CMakeLists.txt file added by add_subdirectory are only visible in that CMakeLists.txt and any further ones it adds via add_subdirectory.  The higher level CMakeLists.txt files would not have the necessary visibility, hence the need to cache the project source directory variable.  To make it behave consistently it would be necessary for cmake to be able to set a variable in the scope of the top level CMakeLists.txt.  Similar to the PARENT_SCOPE that the set() command already has, something like set(foo_SOURCE_PROJECT "path/to/source" ROOT_SCOPE).<br>

<br>
I suspect that the reason cmake is caching these variable is because the set() command doesn't have a ROOT_SCOPE ability and using cache variables was the easiest way to simulate that.  And we have to live with the unfortunate side effect that the cached variables don't exist on the first run but do on subsequent runs.<br>

<br>
</blockquote>
<br></div>
I don't think it would be sufficient to set it in the root scope either since I think each scope has its own copy of the variable.<br>
It would have to be set for all scopes between the root and the current scope.<span class="HOEnZb"><font color="#888888"><br>
<br>
Nils<br>
</font></span></blockquote></div><br></div>