Brad King wrote: >> Having said that, would IMPORTED targets actually be good enough for all >> the things you list, maybe with some wrapper macros ? > > The IMPORTED targets still need to have an IMPORTED_LOCATION that refers > to a real file, so they are not quite equivalent to the proposed INTERFACE > or ALIAS targets. What they all share in common is the lack of build-time > actions.
Actually it might be useful to make it possible to do this: add_library(foo SHARED foo.cpp) add_library(bar SHARED bar.cpp) add_library(iface INTERFACE) target_link_libraries(iface INTERFACE foo bar) and have make iface cause a (re)build of foo and bar if necessary. This would be in conflict with the idea of considering targets with double colons to be imported targets if the INTERFACE_LIBRARY was used in the alias pattern I described before. Perhaps we could do aliasing with a target property instead? add_library(foo SHARED foo.cpp) set_property(TARGET foo APPEND PROPERTY ALIAS_NAME KF5::foo) ? Just another angle to consider in the design of this stuff. > The proposed INTERFACE and ALIAS target types would remain the same when > exported instead of being converted to IMPORTED targets. However, all > their interface content would be mapped to the exported names. > > I think new target types are worth considering for these roles to keep the > "IMPORTED" concept focused on importing targets with files on disk. This might need some deeper consideration. I like that IMPORTED targets can not be re-exported, and I would expect the same for the INTERFACE_LIBRARY type. IMPORTED targets also have a different scope to non-imported targets. I'd expect that if I find_package somewhere and a KF5::iface INTERFACE_LIBRARY results, that follows the same scope rules as KF5::KArchive. The code would become uglier too. We'd need to add special cases for INTERFACE_LIBRARY types in places where we currently check IsImported, eg cmTarget::AddLinkLibrary. Also, commands like target_include_directories() shouldn't work with IMPORTED targets as the first argument, but if such targets are not marked as IMPORTED, there would be no way to enforce that. Some configuration- relevant information is only known to the exporting project upstream. See commit b98d14d40016efee420bee26b9795880fdf6a5f8 (Disallow porcelain to populate includes and defines of IMPORTED targets., 2013-01-21). Thanks, Steve -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
