Thanks, glad you like the idea.<div><br></div><div>I've seen the word "choice" used in many scenarios where the user is given a list to pick from, so it seemed like an appropriate name.</div><div><br></div><div>
You also make a great point about someone already using the word "choice" globally. However, keep in mind it is the integrity of the language we are talking about here. This decision will forever be locked into CMake, so the name you choose must be appropriate and self-documenting. Granted it will be unfortunate that "choice" will possibly cause conflicts with user code, but the design of the CMake language takes precedence IMHO.</div>
<div><br></div><div>For the limited scope of projects this would affect, I would have CMake post a conflict warning that detects when the user has defined a conflicting global variable named "choice" and post a warning or error in the output. After a few minor versions, you can remove this check, but it will at least make it very clear to the users that they simply need to go in and rename their variables, functions, or macros. Just some food for thought. I'd much rather take this approach than be forced to give this new feature an ugly name. I honestly think "choice" is the best name, I can't think of a better one.</div>
<div><br></div><div>Think about it and let me know what you decide. I don't know much about these CMake-language functions you speak of, but it would be interesting to learn about them. Are they covered in detail in the reference documentation, or the wiki?</div>
<div><div><br></div><div>---------</div>Robert Dailey<br>
<br><br><div class="gmail_quote">On Thu, Dec 8, 2011 at 6:00 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;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>
<span class="HOEnZb"><font color="#888888"><br>
<br>
David<br>
</font></span></blockquote></div><br></div>