Hi <span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Chris,</span><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Thanks for the detailed information. SET(.... CACHE ...) is effectively a good workaround.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Gaspard<br>
</span></font><br><div class="gmail_quote">On Sat, Jul 3, 2010 at 1:03 AM, Chris Hillery <span dir="ltr">&lt;<a href="mailto:chillery-cmake@lambda.nu">chillery-cmake@lambda.nu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
There&#39;s a slightly nicer work-around: Change project A&#39;s CMakeLists to set PROJB_OPENCV_LINK as a cache variable, ie, SET(PROJB_OPENCV_LINK NO CACHE BOOLEAN &quot;doc&quot;). I&#39;ve tested it locally and it works the way you want it to.<br>

<br>It seems that CMake divides the world of variables into two classes: cache variables and non-cache variables. Somewhat unfortunately, the same function, SET(), is used to specify values for both kinds, and cache variables &quot;hide&quot; any non-cache variables with the same name. The upshot is that the same SET() command will do different things depending on what&#39;s currently in the cache.<br>

<br>Further confusion here comes from the fact that when a variable is declared as a cache variable (using either option() or set(...CACHE...) ), any current value that the non-cache variable with the same name has is discarded. So the first time you run cmake, PROJB_OPENCV_LINK isn&#39;t a cache variable until it gets to processing projb&#39;s CMakeLists.txt, hence the non-cache value you provided gets dropped. The second time, it&#39;s already a cache variable, so project A&#39;s CMakeLists actually sets the cache variable, and therefore projb&#39;s CMakeLists sees it as you expect.<br>

<br>It&#39;s definitely confusing, but I&#39;m not totally sure what the right solution is. It probably would have been cleaner if CMake made the distinction clear between cache and non-cache variables, but it&#39;s far too late to change that now. Maybe it would be possible to change it such that a cache variable declaration (option() or set(...CACHE...) ) would allow a current non-cache variable of the same name to override the declaration&#39;s default value, in the same way that -D on the command-line does.<br>

<br>Ceej<br>aka Chris Hillery<br><br><div class="gmail_quote"><div><div></div><div class="h5">On Fri, Jul 2, 2010 at 2:52 PM, Gaspard Bucher <span dir="ltr">&lt;<a href="mailto:gaspard@teti.ch" target="_blank">gaspard@teti.ch</a>&gt;</span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div><div></div><div class="h5">
I have two projects: A and B. A depends on B but should set some settings for the proper compilation of B when included in A.<div><br></div><div>==== CMakeLists.txt ==== (project A)</div><div><br></div><div>set(PROJB_OPENCV_LINK NO)</div>


<div><br></div><div>add_subdirectory(vendor/projb)</div><div><br></div><div>==== vendor/projb/CMakeLists.txt === (project B)</div><div><div><br></div><div>option (PROJB_OPENCV_LINK &quot;Set this to NO to link opencv alloc later.&quot; YES)</div>


</div><div><br></div><div>========</div><div><br></div><div>The local value &quot;PROJB_OPENCV_LINK&quot; is overwritten by the option on the first run. If you run cmake a second time, the cached value is seen and takes over so the option does not overwrite.</div>


<div><br></div><div>I do not see any reason why an &quot;option&quot; setting should overwrite a defined variable.</div><div><br></div><div>build &gt; cmake .. ==&gt; fail</div><div><br></div><div>build &gt; cmake .. || cmake .. ==&gt; works. This is absurd.</div>


<div><br></div><font color="#888888"><div>Gaspard</div></font><div><br></div><div><br></div><div>PS: I know there is a workaround by using IF(DEFINED...).</div>
<br></div></div>_______________________________________________<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></blockquote></div><br>
</blockquote></div><br></div>