<div class="gmail_quote">On Thu, Dec 8, 2011 at 3:53 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">The 4th argument to SET (when CACHE is used) is the *type* of the</div></div>
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 above.<br>
<br>
<br>
Still willing to listen, but not budging yet,</blockquote><div><br></div><div>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():</div>
<div><br></div><div>choice( BaseName <span style="font-size: 13px; color: rgb(34, 34, 34); font-family: arial, sans-serif; background-color: rgba(255, 255, 255, 0.917969); ">"binary;octal;decimal;</span><span style="font-size: 13px; color: rgb(34, 34, 34); font-family: arial, sans-serif; background-color: rgba(255, 255, 255, 0.917969); ">hexidecimal"</span> "documentation" 0 )</div>
<div><br></div><div>Parameter 1 is the destination variable, which will be stored in the cache as a STRING type</div><div>Parameter 2 is the tuple, or list of choices for the user.</div><div>Parameter 3 is the documentation string</div>
<div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>What do you think about this?</div></div>