How about overloading the existing OPTION command ?<br><pre>option(<option_variable> "help string describing option" [initial value])</pre>If the initial value supplied is a list then use the first entry. Or maybe a new OPTIONLIST command ?<br>
<br>--<br>Glenn<br><br><div class="gmail_quote">On 9 December 2011 00:00, David Cole <span dir="ltr"><<a href="mailto:david.cole@kitware.com">david.cole@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="HOEnZb"><div class="h5">On Thu, Dec 8, 2011 at 5:43 PM, Robert Dailey <<a href="mailto:rcdailey@gmail.com">rcdailey@gmail.com</a>> wrote:<br>
> On Thu, Dec 8, 2011 at 3:53 PM, David Cole <<a href="mailto:david.cole@kitware.com">david.cole@kitware.com</a>> wrote:<br>
>><br>
>> The 4th argument to SET (when CACHE is used) is the *type* of the<br>
>> cache entry itself. I will not call a cache entry a LIST when it is<br>
>> not actually a list.<br>
>><br>
>> Nor will I accept that the 2nd argument to set should be anything<br>
>> other than the actual value that the cache entry ends up with after<br>
>> the set call.<br>
>><br>
>> Those are the two things I have problems with in your proposal.<br>
>><br>
>> One thing that you can do right now, with no changes to CMake, is<br>
>> write a CMake-language function as a wrapper that "does the right<br>
>> thing" with a list and a cache entry and its default value and setting<br>
>> its existing STRINGS property. As a side benefit, you can make the<br>
>> signature be whatever you want it to be...<br>
>><br>
>> Of course, if we can come to an agreement about a good way to push<br>
>> this into the built-in set command, that would be ideal.<br>
>><br>
>> But I find myself in a rather inflexible mood regarding my two points<br>
>> above.<br>
>><br>
>><br>
>> Still willing to listen, but not budging yet,<br>
><br>
><br>
> I agree with your points. I honestly don't think set() is the right tool for<br>
> the job though. There is already a mechanic in CMake to more conveniently<br>
> set boolean cache variables with the option() command. Likewise, I think we<br>
> should have one for lists, called choice():<br>
><br>
> choice( BaseName "binary;octal;decimal;hexidecimal" "documentation" 0 )<br>
><br>
> Parameter 1 is the destination variable, which will be stored in the cache<br>
> as a STRING type<br>
> Parameter 2 is the tuple, or list of choices for the user.<br>
> Parameter 3 is the documentation string<br>
> Parameter 4 (optional) is the index of an element in the tuple that shall be<br>
> used as the default value. If omitted, the first item in the list will be<br>
> used.<br>
><br>
> Concerning parameter 4, this might be eliminated completely since I see no<br>
> reason why you can't just re-order the list to keep the default item as the<br>
> first item in the list.<br>
><br>
> What do you think about this?<br>
<br>
</div></div>Personally, I like the idea of a whole separate function much better<br>
than cramming it into the already way-overloaded "set".<br>
<br>
Not sure if "choice" is a good name, though. One of the problems with<br>
introducing new function names at the top level like that is we have<br>
no idea if the name is already used in an existing project as a<br>
function or macro in some CMakeLists files. So we can't be cavalier<br>
about deciding to add new top level built-in commands.<br>
<br>
You could certainly implement this as a CMake-language function in<br>
terms of the existing set and STRINGS cache entry property. (And by<br>
giving this advice, I almost guarantee that somebody will do so...)<br>
<br>
I'm gonna sleep on this now. :-)<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
David<br>
--<br>
<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br>