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

[Yuri Timenkov]

On Friday 25 July 2008 12:58:42 Robert Haines wrote:
> 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.
In sub-makefiles you can override variables. But check them only once. 
Moreover, user can push/pop such variables or some of them can be properties.

As for GUI hints, it is better to write descriptive help comments. Or make 
format of strings predefined (but I don't think its a good idea).

>
> > 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!
It's a point. Also, some people prefer to check that source dir != binary dir.

>
> Cheers,
> Rob
>
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake