Ah, nice. Good to know. But then still that cache variable is not created until *after* it was set by Foo, because it is only created when adding the Bar subdirectory, which explains the output.
Sincerely, Jakob On Fri, May 20, 2016 at 1:18 PM, Petr Kmoch <petr.km...@gmail.com> wrote: > The situation already involves a cache variable, though: `option(abc "cmt" > ON)` is just syntactic sugar for `set(abc ON CACHE BOOL "cmt")`. > > Petr > > > On 20 May 2016 at 13:03, Jakob van Bethlehem <jsvanbethle...@gmail.com> > wrote: > >> You don't have to create a cache variable for this. Put yourself in the >> position of CMake; >> * While scanning the CMakeLists.txt of Foo CMake encounters the set(OPT1 >> ON FORCE) command, which tells CMake to create a *variable* called OPT1 >> with value ON >> * Then CMake is asked to include Bar >> * While scanning Bar, CMake encounters the option() command, so it will >> create an option called OPT1 >> * end then.... nothing, CMake finished scanning >> >> Only the second time around, when CMake encounters the set(OPT1..) >> command, it will have gained knowledge of the presence of the OPT1 option, >> and hence it will realize it needs to change that option instead of >> creating a variable with that name. >> >> So to me, your output is exactly as expected. I suspect if you include >> Bar before setting the option, you will get the behaviour you expected. >> This, to me, makes perfect sense, as Bar is a dependency of Foo, and hence >> needs to be setup before you start setting up Foo. You wouldn't compile Foo >> before compiling Bar, so why would that be different for the configuration >> step. >> >> Sincerely, >> Jakob >> >> On Fri, May 20, 2016 at 11:24 AM, Doug Cuthbertson < >> doug.cuthbert...@gmail.com> wrote: >> >>> >>> CMake (version 3.5.2) surprised me with how it's passing values to >>> sub-projects, so I was wondering if this is expected behavior. Here's an >>> example of what I mean. Let's say I have a project Foo in a directory of >>> the same name. It contains a third-party library called Bar which has a >>> CMakeLists.txt file that looks like: >>> >>> cmake_minimum_required(VERSION 2.8.12) >>> >>> option(OPT1 >>> "Set to OFF|ON (default is OFF) to control build of Bar library" >>> OFF) >>> >>> if(OPT1) >>> message("Bar: OPT1 is on") >>> else(OPT1) >>> message("Bar: OPT1 is off") >>> endif(OPT1) >>> >>> I then create CMakeLists.txt for Foo that sets OPT1 to ON and includes >>> Bar: >>> >>> cmake_minimum_required(VERSION 2.8.12) >>> >>> set(OPT1 ON FORCE) >>> if(OPT1) >>> message("Foo: OPT1 is on") >>> else(OPT1) >>> message("Foo: OPT1 is off") >>> endif(OPT1) >>> add_subdirectory(Bar) >>> >>> The first time I run cmake the message output is: >>> >>> Foo: OPT1 is on >>> Bar: OPT1 is off >>> >>> If I run cmake again, I get: >>> >>> Foo: OPT1 is on >>> Bar: OPT1 is on >>> >>> If this is expected behavior, is there any way I can ensure Bar receives >>> the value of OPT1 the first time? It makes a huge difference when the >>> option controls, for example, whether a static or dynamic library will be >>> built. >>> >>> Thanks, >>> Doug >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake >>> >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > >
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake