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

[Brad King]

On 05/27/2015 05:58 PM, Stephen Kelly wrote:
> I see INTERFACE as "has no location" (lower case), and I see 
> IMPORTED_LIBNAME as a location. It specifies to the toolchain-supplied 
> compiler to locate a particular toolchain-supplied library and link it.

I define "location" as "known full path to a file on disk".  Everything
else is just an option to the linker.  So:

- TARGET_FILE is not valid without a "location"
- INTERFACE libraries have no "location"
- TARGET_FILE is not valid for INTERFACE libraries

This is all consistent.  IMPORTED_LIBNAME is not a known full path to a
file on disk.  It is an option to the linker.

>> why not in-line link items?
> it is in-placed because it represents a location. 

It is in-placed because we want to search that library before following
libraries.  In the future more general LINK_ITEMS case it could be a
flag whose order matters.

> The IMPORTED_LIBNAME is different to everything else about how INTERFACE 
> libraries work and the type of transitive properties and porcelain APIs they 
> support.

Since IMPORTED_LIBNAME is a predecessor to a future INTERFACE_LINK_ITEMS
I think this comes down to whether INTERFACE libraries should support
LINK_ITEMS.  See next paragraph.

>>  "To use this interface, put $items in-place on your link line."
> 
> What would the use-case for that be?

One should be able to replace any "raw" link item in a tll() call with
a CMake library target in order to get that same raw item in-place but
also add other usage requirements.  If that raw item is a full path
to a library file then we can do this with a SHARED/STATIC/UNKNOWN
imported library.  I'm proposing that INTERFACE libraries offer LINK_ITEMS
in order to fill this role when the raw item is not a full path to a
library file.

>> Validity of TARGET_FILE should be based on the *type* of the target given,
>> not its configuration.
> 
> then adding another type would solve that issue.

In the long run we're looking for a target type that:

* has no location and does not allow TARGET_FILE,
* supports usage requirements, and
* supports in-place link items.

The INTERFACE type already meets the first two requirements.  Again
the debate comes down to whether interface libraries should support
in-place link items.  I argue above that they should.  If not, then
we will have a new target type that is exactly like INTERFACE but
also supports in-place link items.

>> 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.
> 
> Cool, I think reviewing that separately would be preferable. 
> 
> I'm interested to see what it looks like without IMPORTED_LIBNAME and where 
> the default mapping will come from then, or if there just won't be a default 
> mapping until the INTERFACE library becomes 'particular' to something else 
> with IMPORTED_LIBNAME.

I agree.  We should resolve configuration mapping for INTERFACE
libraries first.

I need to revert the 'imported-interface-libname' topic from 'next'
in preparation for the 3.3 freeze anyway.  After that we can return
first to INTERFACE configuration mapping and later to link items.

Thanks,
-Brad