On Thu, Dec 8, 2011 at 3:09 PM, Alexander Neundorf <a.neundorf-w...@gmx.net> wrote: > On Wednesday 07 December 2011, David Cole wrote: >> On Tue, Dec 6, 2011 at 5:13 PM, Robert Dailey <rcdai...@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 -- 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