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 -- 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
