[cmake-developers] Importing platform SDK libraries without a full path

[Brad King]

On 05/27/2015 02:40 PM, Stephen Kelly wrote:
> By current 'design language' it is not a 'usage requirement', just like 
> IMPORTED_LOCATION, LOCATION, $<TARGET_FILE> and others are not 'usage 
> requirements'.

Sure, but it does tell CMake what to do when a client consumes the
interface.

> I still think the topic overloads INTERFACE libraries with their
> semantic opposite.

I don't agree that this is a semantic opposite:

>  "An INTERFACE target has no LOCATION..."

I think we agree on INTERFACE == "has no LOCATION".
IMPORTED_LIBNAME does not specify a LOCATION.

INTERFACE libraries support specification of link dependencies so why
not in-line link items?  The future LINK_ITEMS work discussed earlier
in the thread would be perfectly valid as a usage requirement of an
interface library:

 "To use this interface, put $items in-place on your link line."

The only way LINK_ITEMS would differ between INTERFACE and other
library types is whether the LOCATION (a.k.a. $<TARGET_FILE:...>)
can be one of the items specified.

IMPORTED_LIBNAME is a predecessor to a possible INTERFACE_LINK_ITEMS
just like IMPORTED_LINK_INTERFACE_LIBRARIES was a predecessor to
INTERFACE_LINK_LIBRARIES.  (This is why I originally named it
IMPORTED_LINK_ITEM, but with the additional restrictions mentioned
in the grandparent of this message the name IMPORTED_LIBNAME is
better.)

> Is it impossible to implement $<TARGET_FILE:...> for UNKNOWN IMPORTED 
> libraries such that it reports an error if IMPORTED_LIBNAME is set?

Of course it is possible to implement that but I don't think it is
the right approach.  Validity of TARGET_FILE should be based on the
*type* of the target given, not its configuration.  See also next
paragraph.

> opengl32 is "unknown", or at least the full path to it is.

The purpose of the UNKNOWN target type is so we can have a library
with a LOCATION but we do not know if it is STATIC or SHARED.
This is different from not having a LOCATION, which is the purpose
of an INTERFACE library.

>> shows how purely IMPORTED_LIBNAME corresponds to IMPORTED_LOCATION.
> 
> I don't think the simplicity of a small hunk is a good deciding factor.

The hunk on its own is not a deciding factor.  The natural correspondence
is the (proposed) deciding factor, and the hunk illustrates the
correspondence.

> I still don't understand why correspondence of MAP_IMPORTED_CONFIG
> and INTERFACE libraries is important, independent of this feature.

Speaking independently from this feature: If a project exports an
INTERFACE full of $<CONFIG:...> generator expressions then the
consuming project needs to be able to map its configurations to
those of the providing project.  Setting MAP_IMPORTED_CONFIG_<CONFIG>
is the way to specify this mapping.  IMPORTED_CONFIGURATIONS allows
a default mapping to be computed.  For non-INTERFACE targets this
default mapping filters on existence of IMPORTED_LOCATION[_<CONFIG>].

Actually I think this can and should be done for INTERFACE libraries
even without IMPORTED_LIBNAME.  I'll look at factoring this part out
into a preceding commit.

> Also, if IMPORTED_LIBNAME and IMPORTED_LOCATION correspond so closely,
> why don't INTERFACE libraries support both?

Because INTERFACE == "has no LOCATION".

-Brad