A totally reasonable suggestion. Patches welcome. ;-)
On Tuesday, August 11, 2015, Dan Kegel <d...@kegel.com> wrote: > 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 > <javascript:;>> 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 <javascript:;>> > 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 <javascript:;>>: > >>> > >>> 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
