Brad King wrote:
> We
> cannot lift the requirement that IMPORTED_LOCATION be a full path
> because that is fundamental to the design of imported targets and
> is needed for things like $ to work correctly.
Could you add a unit test showing what happens when using that genex with a
target which has this property?
Come to think of it, it should probably be an error to use TARGET_FILE on an
INTERFACE target. That doesn't seem to currently be the case.
Can you make it an error to specify both IMPORTED_LOCATION and
IMPORTED_LINK_ITEM on the same target?
> Instead I propose a new IMPORTED_LINK_ITEM[_] property to take
> the place of IMPORTED_LOCATION[_] for an imported INTERFACE
> library. It will allow one to specify exactly one raw item to be
> placed on the link line for the interface library since it has no
> location. For the above case this item would be just 'opengl32'.
> P.S. My original attempt at allowing link item specification was
> much more general. It was an INTERFACE_LINK_ITEMS property on
> INTERFACE libraries that could be specified on in-project targets
> and exported during installation:
>
> Allow INTERFACE libraries to specify link items
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4adad1e
>
> I reverted it from 'next' and never merged it to 'master' due to
> overlap with possible LINK_OPTIONS/ARCHIVE_OPTIONS work discussed
> previously. Instead I propose the more narrow IMPORTED_LINK_ITEM
> approach to resolve the problem for FindOpenGL without tackling the
> larger design goals yet. Basically IMPORTED_LINK_ITEM completes
> the design of IMPORTED_LOCATION as might have been done if interface
> libraries existed when imported targets were first created.
I discussed this feature off-list with Brad over the last few weeks.
I think a remaining problem with this is that is disincentivises acheiving
the larger goals. That is probably a small problem though, as there may be
other incentives for adding INTERFACE_{LINK,ARCHIVE}_OPTIONS. The other
incentives appear to be not-as-strong though.
Given the 'temporaryness' of this feature, it makes sense to narrow the
design and use a more-specific name like IMPORTED_SDK_LIBNAME instead. The
property should not support an item with a prefix of '-' (ie, CMake should
unconditionally add the '-l'). Also, it should not be allowed to be a full
path (should not be allowed to contain a path separator).
> This could also be used for cases like FindThreads and '-pthread'.
I looked into this a bit and I don't think that's a good example usecase for
this feature. The '-pthread' flag is used at both compile time and link
time. On my system it causes '-D_REENTRANT' to be added to the compile line
and '-lpthread' to be added to the link line. On other platforms it might
add '-D_MT' instead apparently
https://groups.google.com/forum/#!msg/comp.programming.threads/NCEpG0EOCCY/gzfXXG6VBv0J
(That's an old post though - needs fact checking)
On FreeBSD, -pthread may cause use of a different libc instead of linking to
the pthread library
https://groups.google.com/d/msg/comp.programming.threads/NCEpG0EOCCY/MDqdY3nB9DMJ
(That's an old post though - needs fact checking)
SolarisStudio does not support -pthread but it does support -mt, which also
has the effect of adding -D_REENTRANT and -lpthreads, with version 12.4 at
least.
XL seems to have a _r invocation mode:
http://www.ibm.com/developerworks/library/l-portsolaris/
So,
1) The -pthread option does not necessarily link to the pthreads library. It
causes the use of multithreading in toolchain/platform libraries, which may
or may not result in linking to the pthreads library. User code wishing to
use the pthreads library and its symbols explicitly should still link to it
explicitly in the normal way. The 'normal way' might be to use a target
provided by FindThreads which has IMPORTED_SDK_LIBNAME property content set
to 'pthread' (so that '-lpthread' is added, not '-pthread').
2) The order of the '-pthread'-like option does not seem to matter. One of
the design goals of IMPORTED_LINK_ITEM is to target cases where the order
does matter.
3) If the '-pthread'-like option is required for linking, then it is also
required for compiling.
So, I don't think IMPORTED_LINK_ITEM should consider this case at all, and
should be designed with a narrower use case accepting only library names and
a property name which reflects that.
== Designing something for -pthread and similar requirements ==
I think this is out of scope for what you are currently designing, but this
is relevant because your design is at least related to the potential future
INTERFACE_LINK_ITEMS and INTERFACE_{LINK,ARCHIVE}_OPTIONS.
Perhaps the way forward for -pthread is {INTERFACE_,}TOOLCHAIN_OPTIONS
properties which contain flags to add to the compile line and the link line.
Other flags which would potentially be used with such a feature include
-std=c++11 (many compilers)
-fno-exce
