<div dir="ltr">The issue with unset(BLAH CACHE) is that it removes the cache entry.  I want to make BLAH undefined in the current scope, without impacting other scopes.<div><br></div><div>Re: lookup, thanks; I get that now.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 17, 2018 at 5:22 AM, Robert Maynard <span dir="ltr"><<a href="mailto:robert.maynard@kitware.com" target="_blank">robert.maynard@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>  I can never actually make it become undefined<br>
<br>
</span>You can, you are missing unset(BLAH CACHE) to tell CMake you want to<br>
undefine the CACHE varibles<br>
<span class=""><br>
> I had been operating under the assumption that there was only one active lookup scope<br>
<br>
</span>Nope CMake lookup is local scope, and than cache. That is how CMake<br>
supports CACHE and local variables with the same name. The rules of<br>
variable lookup are outlined at<br>
<a href="https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#variables" rel="noreferrer" target="_blank">https://cmake.org/cmake/help/<wbr>latest/manual/cmake-language.<wbr>7.html#variables</a><br>
<div class="HOEnZb"><div class="h5">On Thu, Aug 16, 2018 at 6:00 PM James Touton <<a href="mailto:bekenn@gmail.com">bekenn@gmail.com</a>> wrote:<br>
><br>
> Fair enough, but I think that makes the command substantially less useful.  It means that I need to use set(BLAH "") if I want to empty a variable of its contents, and I can never actually make it become undefined, counter to the claim in the documentation:<br>
><br>
> set(BLAH blah CACHE INTERNAL "")<br>
> unset(BLAH)<br>
> if(DEFINED BLAH)<br>
>     message("here") # this message gets printed!<br>
> endif()<br>
><br>
> I am now effectively subject to sabotage from above.<br>
><br>
> I had been operating under the assumption that there was only one active lookup scope, constructed from the previous lookup scope and any new sets/unsets at the current level.  I therefore expected that if a variable were removed from "the" current scope, it would be inaccessible.<br>
><br>
> On Thu, Aug 16, 2018 at 2:46 PM, Robert Maynard <<a href="mailto:robert.maynard@kitware.com">robert.maynard@kitware.com</a>> wrote:<br>
>><br>
>> Looking at the current docs (<br>
>> <a href="https://cmake.org/cmake/help/v3.12/command/unset.html" rel="noreferrer" target="_blank">https://cmake.org/cmake/help/<wbr>v3.12/command/unset.html</a> ) I think the<br>
>> first paragraph needs to be read as a single statement to understand<br>
>> the behavior.<br>
>><br>
>> "Removes the specified variable causing it to become undefined. If<br>
>> CACHE is present then the variable is removed from the cache instead<br>
>> of the current scope."<br>
>><br>
>> I think we can be more explicit by rephrasing as:<br>
>><br>
>> "Makes the local variable variable from the current scope be<br>
>> undefined, If CACHE is present then instead the cache variable is<br>
>> undefined."<br>
>> On Thu, Aug 16, 2018 at 5:38 PM James Touton <<a href="mailto:bekenn@gmail.com">bekenn@gmail.com</a>> wrote:<br>
>> ><br>
>> > I just recently came across this:<br>
>> ><br>
>> > set(BLAH blah CACHE INTERNAL "")<br>
>> > unset(BLAH)<br>
>> > message("BLAH: ${BLAH}")<br>
>> ><br>
>> > Surprisingly (to me), this prints out "blah".  I had expected the unset command to make the cached value inaccessible.  The documentation just states that the function "[r]emoves the specified variable causing it to become undefined."  Is this a bug?  I would prefer for the function to guarantee that ${BLAH} comes up empty.<br>
>> > --<br>
>> ><br>
>> > Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
>> ><br>
>> > Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/<wbr>CMake_FAQ</a><br>
>> ><br>
>> > Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
>> ><br>
>> > CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>support.html</a><br>
>> > CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>consulting.html</a><br>
>> > CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>training.html</a><br>
>> ><br>
>> > Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/<wbr>opensource/opensource.html</a><br>
>> ><br>
>> > Follow this link to subscribe/unsubscribe:<br>
>> > <a href="https://cmake.org/mailman/listinfo/cmake-developers" rel="noreferrer" target="_blank">https://cmake.org/mailman/<wbr>listinfo/cmake-developers</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>