[CMake] New type of cache variable: lists

[David Cole]

On Thu, Dec 8, 2011 at 3:09 PM, Alexander Neundorf
<a.neundorf-work at gmx.net> wrote:
> On Wednesday 07 December 2011, David Cole wrote:
>> 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")
>
>
> Are you sure this would be better ?
> This way, there can be the conflict that the given value may not be contained
> in the list, it is duplication.
> Also, what should be done if the given value is a list itself ?
>
> With the syntax suggested above, introducing a type LIST, both effects are
> impossible.
> But, it would be different than how set() normally works.
> ...but this would have been enabled explicitely by saying it is a LIST.
>
> Alex

My problem with the word "LIST" here is that the *cache entry* itself
is actually and explicitly NOT a LIST in this case. It is a single
non-list item from a list...

I would just like to see a non-confusing way of expressing the concept
if we actually want to consider something like this.


David