<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 1, 2014 at 11:26 AM, 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:16, Matthew Woehlke wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If CMAKE_BINARY_DIR were not cached, yes. But I don't think not caching that is being suggested. It's not clear to me why the *per-project* flavors need to be cached?<br>
<br>
</blockquote>
<br></div>
If they were regular instead of cache variables they would have scopes.<br>
I guess this would break any project that currently referred to their sub- or sibling projects with those variables.<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div><br></div><div>Ya;  promotion to global namespace via addition to cache is a good reason to have them cached</div><div><br></div><div>But, it's not that you have a dynamic build structure that changes often?  It's just that you're trying to reference a variable before it exists; and there's ways around that like set a CMAKE_PASS_2 variable or something to make sure that everything is done the next time... and it fails on a first-run .. but then it doesn't fail, so it's hard to track down where the error was?</div>
<div><br></div><div>maybe cmake --trace ?</div><div><br></div><div><br></div><div><br></div></div></div></div>