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