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.coo...@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.c...@kitware.com> wrote: > >> On Thu, Dec 8, 2011 at 5:43 PM, Robert Dailey <rcdai...@gmail.com> wrote: >> > On Thu, Dec 8, 2011 at 3:53 PM, David Cole <david.c...@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 >> > >
-- 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