[CMake] option bug ?

[Gaspard Bucher]

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-cmake at 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 <gaspard at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100704/3e8a1ccd/attachment-0001.htm>