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
