[CMake] New type of cache variable: lists

[David Cole]

On Thu, Dec 8, 2011 at 4:37 PM, Alexander Neundorf
<a.neundorf-work at gmx.net> wrote:
> On Thursday 08 December 2011, Robert Dailey wrote:
> ...
>> 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.
>
> IMO it's a good thing to be aware of how strings and lists are handled in
> cmake, so you know what is actually going on, and know how to convert between
> them etc. This should make for less surprises.
>
> Alex
> --
>
> 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


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,
David