[CMake] Setting a value in a sub-project

[Doug Cuthbertson]

Petr - using:

    set(OPT1 ON CACHE BOOL "Set to OFF|ON (default is OFF) to control build
of Bar library" FORCE)

works like a champ!

Jakob - Thanks for the suggestion, but I can't put "add_subdirectory(Bar)"
before setting the variable(s) in Foo's CMakeLists.txt, because cmake
finishes configuring everything under Bar before it reads the set commands
in Foo.

Thanks again for all your help.

Doug


On Fri, May 20, 2016 at 8:14 AM, Jakob van Bethlehem <
jsvanbethlehem at gmail.com> wrote:

> 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.kmoch at 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 <jsvanbethlehem at 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.cuthbertson at 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
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160520/330aeb94/attachment.html>