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

[Stephen Kelly]

Brad King wrote:

>> It seems that the meaning of INTERFACE libraries is being overloaded
>> with the opposite of their meaning.
> 
> The meaning of INTERFACE is that it specifies usage requirements
> without itself building anything.

In this, it is the same as IMPORTED libraries.

A key distinction is that INTERFACE libraries might have a place in the 
generated buildsystem, for example to show relevant include directories in 
an IDE. 

> Specifying a library name to
> be placed on the link line is a usage requirement.

IMPORTED_LIBNAME doesn't look like, walk like or quack like a duck, erm, I 
mean usage requirement.

It is designed to not have a porcelain command, a corresponding INTERFACE_ 
property, allow appending, allow generator expressions, be determined by the 
link interface, result in transitive accumulation at the end for consumers.

By current 'design language' it is not a 'usage requirement', just like 
IMPORTED_LOCATION, LOCATION, $<TARGET_FILE> and others are not 'usage 
requirements'.

> The target
> does not build the named library.  I've updated the documentation
> to use better wording for this:
> 
>  An interface library builds no library file itself but does specify
>  usage requirements for its consumers.  The ``IMPORTED_LIBNAME``
>  property may be set to specify a single library name to be placed
>  on the link line in place of the interface library target name as
>  a requirement for using the interface.

I quoted the documentation to show that requiring the IMPORTED_LIBNAME to be 
on INTERFACE libraries is the wrong approach. I still think the topic 
overloads INTERFACE libraries with their semantic opposite.

 http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#interface-libraries

 "An INTERFACE target has no LOCATION and is mutable"

... "or it has a reference to a location relevant only on the filesystem 
which is not mutable"!

The IMPORTED_LIBNAME is a departure from a lot of things in that doc section 
because it overloads INTERFACE libraries with their opposite.

>> How about allowing the IMPORTED_LIBNAME for only 'UNKNOWN IMPORTED'
>> libraries instead.
> 
> We already allow $<TARGET_FILE:...> for UNKNOWN IMPORTED libraries
> so they need an IMPORTED_LOCATION with a full path like any other.

Is it impossible to implement $<TARGET_FILE:...> for UNKNOWN IMPORTED 
libraries such that it reports an error if IMPORTED_LIBNAME is set? I don't 
know why it would be impossible.

Another option is 

 add_library(Foo BIKESHED IMPORTED)

but I don't think that's really necessary, unless it is impossible to 
implement $<TARGET_FILE:...> for UNKNOWN IMPORTED libraries such that it 
reports an error if IMPORTED_LIBNAME is set.

The reason for this IMPORTED_LIBNAME feature is that the opengl32 is 
"unknown", or at least the full path to it is.

>> Also the changes regarding MAP_IMPORTED_CONFIG for INTERFACE libraries
>> can be implemented separately if they make sense (I don't know what's
>> motivating them) instead having them as a side effect of the branch as it
>> is currently.
> 
> They are needed to select the proper IMPORTED_LIBNAME_<CONFIG>
> possibly mapped from the consuming project's configuration.
> The fact that this could be done with just the hunk
> 
>  -  std::string const locPropBase = "IMPORTED_LOCATION";
>  +  std::string const locPropBase =
>  +    this->GetType() == INTERFACE_LIBRARY?
>  +    "IMPORTED_LIBNAME" : "IMPORTED_LOCATION";
> 
> shows how purely IMPORTED_LIBNAME corresponds to IMPORTED_LOCATION.

I don't think the simplicity of a small hunk is a good deciding factor. 
Implementing the feature for UNKNOWN_LIBRARY would be almost as simple, and 
within the bounds of reasonably simple as far as I can tell. Maybe I'm 
missing something that makes that hard or impossible.

Anyway, my remark wasn't about correspondance of IMPORTED_LIBNAME and 
IMPORTED_LOCATION, but correspondance of MAP_IMPORTED_CONFIG and INTERFACE 
libraries. I still don't understand why correspondance of 
MAP_IMPORTED_CONFIG and INTERFACE libraries is important, independent of 
this feature. MAP_IMPORTED_CONFIG appears to be relevant to 
IMPORTED_LIBNAME, but I as don't see what couples that to INTERFACE 
libraries, I find it hard to reason about that part/intention of the patch.

Also, if IMPORTED_LIBNAME and IMPORTED_LOCATION correspond so closely, why 
don't INTERFACE libraries support both? For me the reason is that 
IMPORTED_LIBNAME and IMPORTED_LOCATION correspond, but IMPORTED_LIBNAME and 
INTERFACE libraries do not.

Thanks,

Steve.