[CMake] New type of cache variable: lists

[Alexander Neundorf]

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