[cmake-developers] RPATH info missing when using a genex (Was: Recommended use of imported targets...)
Stephen Kelly
steveire at gmail.com
Thu Feb 28 11:21:08 EST 2013
Brad King wrote:
> On 02/27/2013 04:37 PM, Alexander Neundorf wrote:
>> 1) we should continue to recommend to use the variables (which will now
>> be set to the name of the target). In case of typos, this will lead to an
>> empty variable (as it did before with Find-modules), and undefined
>> references when linking. This is at least no regression.
>> Also, it shields users somewhat from potential renaming of the imported
>> targets.
>
> This is up to individual projects based on their own requirements.
> Some interface may be more stable than others. I do not think any
> general recommendation can be made without lots of contingencies.
>
>> safe_target_link_libraries(hello TARGET:foox
>> FILE:/opt/lib/libbar.a
>> LIBRARY:png)
>
> Sure, it is possible to make interfaces typo-resistant by adding lots
> of syntax. Part of the simplicity tll() is that it has little syntax.
>
> Note that FILE: and LIBRARY: do not need to be distinguished from
> one another because files always have paths (/) and library names
> never do. For TARGET: we already have $<TARGET_NAME:foox>, which
> IIUC can be used in tll already (Steve?).
That works, but it doesn't check anything. Checking is only done at export-
time (though it could also check for existence at generate time).
I've just tried it though with an odd result:
target_link_libraries(foo Qt4::QtCore)
gives:
/usr/lib/icecc/bin/c++ -fPIC -shared -Wl,-soname,libfoo.so -o libfoo.so
CMakeFiles/foo.dir/empty.cpp.o
/home/stephen/dev/prefix/qt48/lib/libQtCore.so -Wl,-
rpath,/home/stephen/dev/prefix/qt48/lib
but
target_link_libraries(foo $<TARGET_NAME:Qt4::QtCore>)
gives
/usr/lib/icecc/bin/c++ -fPIC -shared -Wl,-soname,libfoo.so -o libfoo.so
CMakeFiles/foo.dir/empty.cpp.o
/home/stephen/dev/prefix/qt48/lib/libQtCore.so
rpath info is missing. This is the case with the genex $<1:Qt4::QtCore> too.
Where should that be added?
Thanks,
Steve.
More information about the cmake-developers
mailing list