[CMake] Feature wish - constrained string values for configuration options

Robert Haines rhaines at manchester.ac.uk
Fri Jul 25 04:58:42 EDT 2008


On 24 Jul 2008, at 23:17, Alexander Neundorf wrote:

> On Thursday 24 July 2008, Robert Haines wrote:
>> On 18 Jul 2008, at 18:40, Bill Hoffman wrote:
> ...
>>> However, it is not that easy to implement, since the basic type in
>>> CMake is a string.  There is no way to constrain the value of a
>>> variable, or even store more information about a variable.
>>
>> I decided to knock something up using macros that does what I need.  
>> It
>> obviously doesn't constrain choices in a UI or provide a drop down
>> menu but it does raise an error if the user tries to configure a
>> project with a value set outside of a list of allowed values. It does
>> enough for me for now and hopefully someone else will find it useful.
>>
>> There are two versions. My first attempt needs you to define your
>> variable first:
>> set(TEST_OPT "None" CACHE STRING "Some Documentation")
>> then call the assert_option macro like this:
>> assert_option(${TEST_OPT} "TEST_OPT" "None, One, Two, Three")
>>
>> But I felt that was a little ungainly so my second attempt is called
>> like this (without a prior "set"):
>> select_option(VARIABLE INITIAL-VALUE ALLOWED-VALUE-LIST  
>> DOCUMENTATION)
>> example:
>> select_option(TEST_OPT "None" "None, One, Two, Three" "Some
>> Documentation")
>>
>> You can grab it straight from my git repository here:
>> http://git.kato.mvc.mcc.ac.uk/zzcgurh/option-macros.git/
>>
>> If you just want a tarball use the "snapshot" link on that page - you
>> want the line with the yellow "v-1.0" tag on it.
>>
>> Once you've got it (and un-tarred it) you can just point ccmake at  
>> the
>> directory as it has a full top-level CMakeLists.txt which uses both
>> forms of the macro.
>
> The problem with that is that you can still set the variable to  
> different
> values afterwards, and I guess this is what Bill means with "there  
> is no way
> to constrain the value".

What to you mean by "afterwards"? In the CMakeCache.txt? In the  
Makefiles? There comes a point where CMake has to say "you do that and  
you're on your own". I can only test on Makefile type builds so I  
don't know to what extent this sort of thing can be messed about with  
in an IDE such as VS or Xcode. Actually, I'd be surprised if most  
IDE's don't have an enum type that this sort of thing could be passed  
through as.

> So I guess it's not good enough as a generic solution for cmake :-/

Of course not, the real solution (if there is one) needs to go into  
the CMake core code rather than as a macro.

How does the CMAKE_BUILD_TYPE set of options handle this type of  
thing? It looks like it just ignores it if it's set to something that  
it doesn't recognise but I find it hard to believe that that is a  
better solution than at least some minimal checking. At the moment you  
could set CMAKE_BUILD_TYPE to Relese by mistake and never be told that  
it's a nonsense value!

Cheers,
Rob



More information about the CMake mailing list