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"><<a href="mailto:chillery-cmake@lambda.nu">chillery-cmake@lambda.nu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
There's a slightly nicer work-around: Change project A's CMakeLists to set PROJB_OPENCV_LINK as a cache variable, ie, SET(PROJB_OPENCV_LINK NO CACHE BOOLEAN "doc"). I'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 "hide" any non-cache variables with the same name. The upshot is that the same SET() command will do different things depending on what'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't a cache variable until it gets to processing projb's CMakeLists.txt, hence the non-cache value you provided gets dropped. The second time, it's already a cache variable, so project A's CMakeLists actually sets the cache variable, and therefore projb's CMakeLists sees it as you expect.<br>
<br>It's definitely confusing, but I'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'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'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"><<a href="mailto:gaspard@teti.ch" target="_blank">gaspard@teti.ch</a>></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 "Set this to NO to link opencv alloc later." YES)</div>
</div><div><br></div><div>========</div><div><br></div><div>The local value "PROJB_OPENCV_LINK" 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 "option" setting should overwrite a defined variable.</div><div><br></div><div>build > cmake .. ==> fail</div><div><br></div><div>build > cmake .. || cmake .. ==> 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>