Hi Chris,
Thanks for the detailed information. SET( CACHE ...) is effectively a
good workaround.
Gaspard
On Sat, Jul 3, 2010 at 1:03 AM, Chris Hillery chillery-cm...@lambda.nuwrote:
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.
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.
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.
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.
Ceej
aka Chris Hillery
On Fri, Jul 2, 2010 at 2:52 PM, Gaspard Bucher gasp...@teti.ch wrote:
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.
CMakeLists.txt (project A)
set(PROJB_OPENCV_LINK NO)
add_subdirectory(vendor/projb)
vendor/projb/CMakeLists.txt === (project B)
option (PROJB_OPENCV_LINK Set this to NO to link opencv alloc later.
YES)
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.
I do not see any reason why an option setting should overwrite a defined
variable.
build cmake .. == fail
build cmake .. || cmake .. == works. This is absurd.
Gaspard
PS: I know there is a workaround by using IF(DEFINED...).
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
