[CMake] New type of cache variable: lists

[Robert Dailey]

I didn't want option() to become the new, overly used and overly
complicated set(), so choice() seemed more appropriate. It is a lot more
self-documenting as well. I think of option as providing a boolean toggle,
not a list of strings to choose from.

---------
Robert Dailey


On Sat, Dec 10, 2011 at 7:39 AM, Glenn Coombs <glenn.coombs at gmail.com>wrote:

> How about overloading the existing OPTION command ?
>
> option(<option_variable> "help string describing option" [initial value])
>
> If the initial value supplied is a list then use the first entry.  Or
> maybe a new OPTIONLIST command ?
>
> --
> Glenn
>
> On 9 December 2011 00:00, David Cole <david.cole at kitware.com> wrote:
>
>> 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
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111211/7ab0af94/attachment.htm>