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.nu>wrote: > 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