[CMake] Does SET_TARGET_PROPERTIES(foo PROPERTIES INSTALL_RPATH /path1; /path2) still silently ignore path2?

David Cole DLRdave at aol.com
Tue Aug 11 12:06:42 EDT 2015


A totally reasonable suggestion. Patches welcome. ;-)


On Tuesday, August 11, 2015, Dan Kegel <dank at 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 <DLRdave at 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 <dank at 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" <
> nilsgladitz at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150811/f04b1939/attachment.html>


More information about the CMake mailing list