[CMake] How the heck does one set options?

[Michael Hertling]

On 11/03/2011 08:20 PM, Dan Kegel wrote:
> Thanks for the authoritative answer.
> 
> I'm now using
> 
> SET(gtest_force_shared_crt on CACHE BOOL
>   "Use shared (DLL) run-time lib even when Google Test is built as static lib.")
> add_subdirectory(gtest)
> include_directories(gtest/include)
> add_executable(mymain mymain.cpp)
> target_link_libraries(mymain gtest_main)
> 
> in my test app, and it's working with visual c++ 2008 (will try linux shortly).

Yes, this should work well if the gtest_force_shared_crt variable is
to have a different default value than the one provided by the gtest
CMakeLists.txt. However, variables preset with OPTION() are usually
intended to be at the user's disposal - otherwise, they wouldn't be
options - so a project should definitely pass through without errors
regardless to which values these variable are set at first. In other
words, it shouldn't be necessary to preset gtest_force_shared_crt to
ON for the project to succeed. Of course, inter-option dependencies
must be handled properly, see the CMakeDependentOption module, e.g.

> I confess, I've been putting off understanding cmake's variable scoping
> and caching; I guess I'll have to pay more attention to it.
> I hope the library of worked examples I'm putting together at
> http://code.google.com/p/winezeug/source/browse/#svn/trunk/cmake_examples
> will eventually help other doc-o-phobes come up the curve faster.

IMO, the actual difficulty is to understand

SET(<VARIABLE> <VALUE> CACHE <TYPE> "...")

as this command can

- write to the cache and to the current scope,
- write to the current scope only,
- do nothing.

Moreover, the potential difference between -D<VARIABLE>=<VALUE> and
-D<VARIABLE>:<TYPE>=<VALUE> is a bug, IMO, since <TYPE> should only
be relevant for the GUIs, but not for the resulting configuration.
Anyway, if one conceptually distinguishes "cache" variables from
"scope" variables, everything is fine.

Regards,

Michael