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.<br clear="all">
<div><br></div><div>---------</div>Robert Dailey<br>
<br><br><div class="gmail_quote">On Sat, Dec 10, 2011 at 7:39 AM, Glenn Coombs <span dir="ltr"><<a href="mailto:glenn.coombs@gmail.com">glenn.coombs@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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"><div><div class="h5">On 9 December 2011 00:00, David Cole <span dir="ltr"><<a href="mailto:david.cole@kitware.com" target="_blank">david.cole@kitware.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5">
<div><div>On Thu, Dec 8, 2011 at 5:43 PM, Robert Dailey <<a href="mailto:rcdailey@gmail.com" target="_blank">rcdailey@gmail.com</a>> wrote:<br>
> On Thu, Dec 8, 2011 at 3:53 PM, David Cole <<a href="mailto:david.cole@kitware.com" target="_blank">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></div><div><div><br>
<br>
David<div class="im"><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></div></blockquote></div><br>
</blockquote></div><br>