[CMake] New type of cache variable: lists

[David Cole]

On Tue, Dec 6, 2011 at 5:13 PM, Robert Dailey <rcdailey at gmail.com> wrote:
> Thanks for that info David.

You're welcome.


>
> I have to say that the way this is setup feels kind of duct-taped together.

It is kind of duct-taped together. (It was better than using WD-40...)


> I expected the documentation for such a feature to be under 'set' in the
> docs, but it wasn't.

Good idea to cross-link set and the STRINGS property. Too bad we don't
have a good way of specifying see also links in our documentation yet.
We are open to patches that clarify documentation when deficiencies
like this are noticed.


> 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....


> 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?


David

>
> On Tue, Dec 6, 2011 at 3:32 PM, David Cole <david.cole at kitware.com> wrote:
>>
>> On Tue, Dec 6, 2011 at 4:26 PM, David Doria <daviddoria at gmail.com> wrote:
>> > On Tue, Dec 6, 2011 at 4:19 PM, Robert Dailey <rcdailey at gmail.com>
>> > wrote:
>> >> Has anyone thought of creating a "LIST" type for cache variables? In
>> >> CMake
>> >> GUI on Windows, this would be represented by a combo-box or drop-down
>> >> box
>> >> that allows the user to pick one item out of a list of available items.
>> >>
>> >> Is this possible?
>> >
>> > I definitely agree. An immediate use case is for the CMAKE_BUILD_TYPE
>> > variable. I added a feature request here a while back:
>> > http://public.kitware.com/Bug/view.php?id=11806
>> >
>> > 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
>>
>> From that bug report:
>>
>>  For cmake-gui this can be done by setting the STRINGS property of
>> the cache entry:
>>  set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS
>> "DEBUG;RELEASE;MY_BUILD_TYPE")
>>
>> And here's a blog about that feature:
>>
>>  http://www.kitware.com/blog/home/post/82
>>
>> So, yes, Robert, it is possible. And David D., I'm not sure how we
>> could make it automatic as you request in the bug report.
>>
>>
>> HTH,
>> David C.
>
>