[CMake] New type of cache variable: lists

Robert Dailey rcdailey at gmail.com
Thu Dec 8 17:43:15 EST 2011


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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111208/7b196281/attachment.htm>


More information about the CMake mailing list