[CMake] New type of cache variable: lists

[Robert Dailey]

On Tue, Dec 6, 2011 at 6:39 PM, David Cole <david.cole at kitware.com> wrote:

> > Plus the option in the list that is the default must be
> > specified in 2 different locations. I think a cleaner solution could be
> > implemented:
> >
> > set( BaseName "binary;octal;decimal;hexidecimal" CACHE LIST
> "Documentation"
> > )
> >
> > The first item in the list would be the default.
> >
>
> So you propose that
>
>  set( BaseName "binary;octal;decimal;hexidecimal" CACHE LIST
> "Documentation")
>
> yields "${BaseName}" equal to "binary"?
>
> That would be rather odd, since the existing:
>
>  set( BaseName "binary;octal;decimal;hexidecimal" CACHE STRING
> "Documentation")
>
> yields "${BaseName}" equal to "binary;octal;decimal;hexidecimal"...
>
> And everywhere else in the CMake documentation we treat STRING and
> LIST as interchangeable entities, where a LIST is simply a string that
> has semi-colon delimiters between the items of the list...
>
> If we were to make a change like this to add to the "set" command, I'd
> prefer to see something like the following:
>
>  set( BaseName "binary" CACHE STRING "Documentation"
> CONSTRAIN_TO_STRINGS "binary;octal;decimal;hexidecimal")
>
> The type of the cache entry in question is most definitely a STRING,
> and furthermore in this case a non-list STRING. I don't think we want
> it to be a list. We want to give a list of values to which to
> constrain the string....
>

Here you are still repeating the default value twice, which is error prone.
If I change that 1 item in one location, I have to change it in another. I
should only have to edit it once should I need to.

It is a list of literal objects. I would rather see your revised
implementation look like this (again revised):

set( BaseName "binary;octal;decimal;hexidecimal" CACHE LIST "Documentation"
DEFAULT 0 )

In this case you set the default value explicitly by index, that way you do
not have to repeat the value itself.

Or you could do this:

set( BaseName 0 CACHE LIST "Documentation"
ITEMS "binary;octal;decimal;hexidecimal" )

In this second case, "LIST" is just syntactic sugar for "STRING", and the
CMake compiler will replace the list index (in this case 0) with the
corresponding string value in the list provided after the ITEMS parameter,
which in this case would be "binary". This is basically the same as your
revised example, but without the duplication of the "binary" item in the
list.


> > Wouldn't this work and be slightly cleaner and more straight-forward?
> Plus
> > you could keep the documentation for this feature contained to the 'set'
> > command in the docs like other cache variable types. I just don't think
> > lists should be handled differently.
>
> Perhaps you still need to make the mental leap that a list is a
> string, and that a string is a list, in the CMake language?


The fact that a list is a string is an implementation detail of CMake
itself. As a user of CMake I shouldn't need to concern myself with such
matters. I think of a collection of items in CMake as a list. The syntax is
different for lists as well. There are non-literal parts of the string that
are treated special by CMake, which makes it not a string at all actually.
Strings are literal objects that get no extra processing beyond escape
sequences.

Perhaps the mental leap is the inverse of what you propose: A list is not a
string and should not be a string (although the syntax differences between
them are minor). Also keep in mind that I'm talking about state of mind.
The CMake code might argue against me, but when I'm using CMake code I
don't care about what CMake is calling a list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111208/6fac2ad0/attachment.htm>