A totally reasonable suggestion. Patches welcome. ;-)<div><br><br>On Tuesday, August 11, 2015, Dan Kegel <<a href="mailto:dank@kegel.com">dank@kegel.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Aha.  Well, how about sanity checks on the names of the properties?<br>
Maybe a new policy could be added that property names have to be<br>
declared (and the ones supported by cmake itself would be predeclared,<br>
of course), and setting an undeclared one would throw an error.<br>
<br>
On Tue, Aug 11, 2015 at 6:57 AM, David Cole <<a href="javascript:;" onclick="_e(event, 'cvml', 'DLRdave@aol.com')">DLRdave@aol.com</a>> wrote:<br>
> The final args to set_target_properties are any number of name/value pairs:<br>
><br>
> <a href="http://www.cmake.org/cmake/help/v3.3/command/set_target_properties.html" target="_blank">http://www.cmake.org/cmake/help/v3.3/command/set_target_properties.html</a><br>
><br>
> The only thing we could do there is look for an even number of args, and<br>
> catch possible problems half the time... I'm not sure if there are any<br>
> restrictions on property names, but for this command, and its historical<br>
> args composition, we are stuck with "prop1 value1 prop2 value2 ..." as the<br>
> final args.<br>
><br>
> Having said all that, there are some checks on the args to the function, so<br>
> it looks like you got "unlucky" with the number of paths in the prop value.<br>
> I would advise against playing roulette for a while... ;-)<br>
><br>
> <a href="https://github.com/Kitware/CMake/blob/422d3f68/Source/cmSetTargetPropertiesCommand.cxx#L36-L40" target="_blank">https://github.com/Kitware/CMake/blob/422d3f68/Source/cmSetTargetPropertiesCommand.cxx#L36-L40</a><br>
><br>
><br>
> HTH,<br>
> David C.<br>
><br>
><br>
> On Tuesday, August 11, 2015, Dan Kegel <<a href="javascript:;" onclick="_e(event, 'cvml', 'dank@kegel.com')">dank@kegel.com</a>> wrote:<br>
>><br>
>> Thanks.  Should set_target_properties throw an error if given too many<br>
>> arguments, to catch this problem?<br>
>><br>
>> Am 10.08.2015 11:43 nachm. schrieb "Nils Gladitz" <<a href="javascript:;" onclick="_e(event, 'cvml', 'nilsgladitz@gmail.com')">nilsgladitz@gmail.com</a>>:<br>
>>><br>
>>> On 08/11/2015 12:51 AM, Dan Kegel wrote:<br>
>>>><br>
>>>> With cmake 2.8.12.2,<br>
>>>><br>
>>>> SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH ${my_install_rpath})<br>
>>>><br>
>>>> silently only obeys the first directory in the rpath, but<br>
>>>><br>
>>>> SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH<br>
>>>> "${my_install_rpath}")<br>
>>>><br>
>>>> works.  Is it still that way in the latest cmake, and is there<br>
>>>> already a bug for this?  I looked,<br>
>>>> but didn't see one.<br>
>>><br>
>>><br>
>>> It should still be this way.<br>
>>><br>
>>> The command takes any number of key value pairs where each key and value<br>
>>> are a single argument.<br>
>>><br>
>>> A CMake list when expanded unquoted results in one argument per list<br>
>>> item.<br>
>>><br>
>>> When a list is quoted it is a single argument.<br>
>>><br>
>>> Expansion of variables happens before the command itself gets its<br>
>>> arguments.<br>
>>><br>
>>> Without the quotes the first item in my_install_rpath will be interpreted<br>
>>> as a value while the second will be a key etc.<br>
>>><br>
>>> It might therefor be more of a language rather than command specific<br>
>>> issue.<br>
>>><br>
>>> One clean alternative is to use set_property() instead since unlike<br>
>>> set_target_properties() it takes a single key but any number of value<br>
>>> arguments.<br>
>>><br>
>>> Nils<br>
</blockquote></div>