Brad King wrote:
> 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.
So far I have not included IMPORTED_LOCATION, LOCATION, $<TARGET_FILE> in
what I consider 'usage requirements' in the design language.
I think you're saying that needs to change. There may be documentation to
update.
>> "An INTERFACE target has no LOCATION..."
>
> I think we agree on INTERFACE == "has no LOCATION".
> IMPORTED_LIBNAME does not specify a LOCATION.
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.
> INTERFACE libraries support specification of link dependencies so why
> not in-line link items?
Perhaps because this is one particular item, because it is in-placed because
it represents a location.
Currently INTERFACE libraries are not 'particular' to anything. All of their
content interesting to the local buildsystem is INTERFACE properties and
generator expressions. They don't represent 'a particular thing', they're
just computers of buildsystem properties.
Also because INTERFACE Link dependencies are not specific to INTERFACE
libraries and supporting INTERFACE link dependencies seems to me like a
natural thing to do because INTERFACE libraries simply support all INTERFACE
transitive properties.
The IMPORTED_LIBNAME is different to everything else about how INTERFACE
libraries work and the type of transitive properties and porcelain APIs they
support.
> 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."
What would the use-case for that be? As far as I know, there wouldn't be a
need for that for SDK-libraries (covered by IMPORTED_LIBNAME), toolchain
options needed at both compile and link time (covered by TOOLCHAIN_OPTIONS),
interface link/archive options (covered by
INTERFACE_{LINK,ARCHIVE}_OPTIONS), or direct link dependencies (covered by
target_link_libraries).
Maybe LINK_ITEMS should be disallowed for INTERFACE libraries too. In what I
posted before, there were only example use cases for targets which add
something to the link line anyway and which the user wants to wrap in other
options.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13284/focus=13296
I can't think of an example of "To use this interface, put $items in-place
on your link line." which doesn't overlap feature-wise with another feature
(such as INTERFACE_LINK_OPTIONS or LINK_ITEMS on a non-INTERFACE library).
It might be good to find one.
(note that my reference to LINK_ITEMS above is a reference to the design I
posted which does not include a INTEFACE_LINK_ITEMS property).
> 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.
Ok. I don't know why not. If it is only because:
> 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.
Maybe adding another type is something you want to avoid which is motivating
other design choices here.
> 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.
Yes, admittedly this proposal overloads the meaning of "UNKNOWN". I don't
think that's problematic, but a new type would also solve that.
>>> 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.
A new type would show the same 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>].
And the proposal is for INTERFACE targets to do default mapping based on a
filesystem-content-specific && config-specific property.
> 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.
Thanks,
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
