Aha. Well, how about sanity checks on the names of the properties? Maybe a new policy could be added that property names have to be declared (and the ones supported by cmake itself would be predeclared, of course), and setting an undeclared one would throw an error.
On Tue, Aug 11, 2015 at 6:57 AM, David Cole <dlrd...@aol.com> wrote: > The final args to set_target_properties are any number of name/value pairs: > > http://www.cmake.org/cmake/help/v3.3/command/set_target_properties.html > > The only thing we could do there is look for an even number of args, and > catch possible problems half the time... I'm not sure if there are any > restrictions on property names, but for this command, and its historical > args composition, we are stuck with "prop1 value1 prop2 value2 ..." as the > final args. > > Having said all that, there are some checks on the args to the function, so > it looks like you got "unlucky" with the number of paths in the prop value. > I would advise against playing roulette for a while... ;-) > > https://github.com/Kitware/CMake/blob/422d3f68/Source/cmSetTargetPropertiesCommand.cxx#L36-L40 > > > HTH, > David C. > > > On Tuesday, August 11, 2015, Dan Kegel <d...@kegel.com> wrote: >> >> Thanks. Should set_target_properties throw an error if given too many >> arguments, to catch this problem? >> >> Am 10.08.2015 11:43 nachm. schrieb "Nils Gladitz" <nilsglad...@gmail.com>: >>> >>> On 08/11/2015 12:51 AM, Dan Kegel wrote: >>>> >>>> With cmake 2.8.12.2, >>>> >>>> SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH ${my_install_rpath}) >>>> >>>> silently only obeys the first directory in the rpath, but >>>> >>>> SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH >>>> "${my_install_rpath}") >>>> >>>> works. Is it still that way in the latest cmake, and is there >>>> already a bug for this? I looked, >>>> but didn't see one. >>> >>> >>> It should still be this way. >>> >>> The command takes any number of key value pairs where each key and value >>> are a single argument. >>> >>> A CMake list when expanded unquoted results in one argument per list >>> item. >>> >>> When a list is quoted it is a single argument. >>> >>> Expansion of variables happens before the command itself gets its >>> arguments. >>> >>> Without the quotes the first item in my_install_rpath will be interpreted >>> as a value while the second will be a key etc. >>> >>> It might therefor be more of a language rather than command specific >>> issue. >>> >>> One clean alternative is to use set_property() instead since unlike >>> set_target_properties() it takes a single key but any number of value >>> arguments. >>> >>> Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
