So I created a small project to attempt to reproduce this problem on a much smaller scale, but it functioned as designed in that case.<div><br></div><div>It's only in my large, corporate project that this happens. Is there any way to dump a "scope stack" or call stack of some sort in CMake? That way I can see what the real parent scope is? Maybe it's not what I think it is.<br clear="all">
<div><br></div><div>---------</div>Robert Dailey<br>
<br><br><div class="gmail_quote">On Thu, Oct 20, 2011 at 3:42 PM, Michael Hertling <span dir="ltr"><<a href="mailto:mhertling@online.de">mhertling@online.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On 10/20/2011 08:44 PM, Robert Dailey wrote:<br>
> On Thu, Oct 20, 2011 at 12:56 PM, Michael Hertling <<a href="mailto:mhertling@online.de">mhertling@online.de</a>>wrote:<br>
><br>
>> On 10/20/2011 06:59 PM, Robert Dailey wrote:<br>
>>> Let me ask this,<br>
>>><br>
>>> What would be the parent of a function located in the root CMakeLists<br>
>> file<br>
>>> but called from a subordinate CMakeLists file?<br>
>><br>
>> It's the subordinate CMakeLists.txt file's parent, but what Michael<br>
>> probably aims at is that some variables undergo a lazy evaluation,<br>
>> i.e. when you say<br>
>><br>
>> set( CMAKE_MFC_FLAG 2 )<br>
>> add_executable( ... )<br>
>><br>
>> in a function, and CMAKE_MFC_FLAG isn't evaluated till generation time,<br>
>> the value "2" will be lost since it is limited to the function's scope.<br>
>> See the following project for an example:<br>
><br>
><br>
> Does this lazy evaluation also apply to variables set with PARENT_SCOPE? If<br>
> so, that would explain why not even that helped.<br>
<br>
</div></div>If the variable is subject to lazy evaluation - not all variables are,<br>
and I don't know if CMAKE_MFC_FLAG is - it doesn't matter how it has<br>
received its final value at the concerned CMakeLists.txt's end, i.e.<br>
if it has been set in the CMakeLists.txt immediately or in a function<br>
using PARENT_SCOPE or in a subordinate CMakeLists.txt file entered by<br>
ADD_SUBDIRECTORY(), also using PARENT_SCOPE; the latest value will be<br>
in effect for the generation step.<br>
<br>
BTW, I talked trash:<br>
<div class="im"><br>
>>> What would be the parent of a function located in the root CMakeLists<br>
>> file<br>
>>> but called from a subordinate CMakeLists file?<br>
>><br>
</div>>> It's the subordinate CMakeLists.txt file's parent, [...]<br>
<br>
This is not true, of course. A function called from a CMakeLists.txt<br>
file opens up its own scope, and its parent scope is the one of the<br>
calling CMakeLists.txt file, not the one of the latter's parent.<br>
Sorry about the mistake.<br>
<br>
If your issue still persists, could you come up with a minimal<br>
but complete exemplary project for further investigation?<br>
<br>
Regards,<br>
<div><div></div><div class="h5"><br>
Michael<br>
--<br>
<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br></div>