[CMake] New type of cache variable: lists

[Robert Dailey]

Thanks, glad you like the idea.

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.

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.

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.

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?

---------
Robert Dailey


On Thu, Dec 8, 2011 at 6:00 PM, David Cole <david.cole at kitware.com> wrote:

> On Thu, Dec 8, 2011 at 5:43 PM, Robert Dailey <rcdailey at gmail.com> wrote:
> > On Thu, Dec 8, 2011 at 3:53 PM, David Cole <david.cole at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111208/689b3cb3/attachment-0001.htm>