[CMake] New type of cache variable: lists

[David Cole]

On Thu, Dec 8, 2011 at 5:43 PM, Robert Dailey <rcdailey at gmail.com> wrote:
> On Thu, Dec 8, 2011 at 3:53 PM, David Cole <david.cole at kitware.com> wrote:
>>
>> The 4th argument to SET (when CACHE is used) is the *type* of the
>> cache entry itself. I will not call a cache entry a LIST when it is
>> not actually a list.
>>
>> Nor will I accept that the 2nd argument to set should be anything
>> other than the actual value that the cache entry ends up with after
>> the set call.
>>
>> Those are the two things I have problems with in your proposal.
>>
>> One thing that you can do right now, with no changes to CMake, is
>> write a CMake-language function as a wrapper that "does the right
>> thing" with a list and a cache entry and its default value and setting
>> its existing STRINGS property. As a side benefit, you can make the
>> signature be whatever you want it to be...
>>
>> Of course, if we can come to an agreement about a good way to push
>> this into the built-in set command, that would be ideal.
>>
>> But I find myself in a rather inflexible mood regarding my two points
>> above.
>>
>>
>> Still willing to listen, but not budging yet,
>
>
> I agree with your points. I honestly don't think set() is the right tool for
> the job though. There is already a mechanic in CMake to more conveniently
> set boolean cache variables with the option() command. Likewise, I think we
> should have one for lists, called choice():
>
> choice( BaseName "binary;octal;decimal;hexidecimal" "documentation" 0 )
>
> Parameter 1 is the destination variable, which will be stored in the cache
> as a STRING type
> Parameter 2 is the tuple, or list of choices for the user.
> Parameter 3 is the documentation string
> Parameter 4 (optional) is the index of an element in the tuple that shall be
> used as the default value. If omitted, the first item in the list will be
> used.
>
> Concerning parameter 4, this might be eliminated completely since I see no
> reason why you can't just re-order the list to keep the default item as the
> first item in the list.
>
> What do you think about this?

Personally, I like the idea of a whole separate function much better
than cramming it into the already way-overloaded "set".

Not sure if "choice" is a good name, though. One of the problems with
introducing new function names at the top level like that is we have
no idea if the name is already used in an existing project as a
function or macro in some CMakeLists files. So we can't be cavalier
about deciding to add new top level built-in commands.

You could certainly implement this as a CMake-language function in
terms of the existing set and STRINGS cache entry property. (And by
giving this advice, I almost guarantee that somebody will do so...)

I'm gonna sleep on this now. :-)


David