Ben Boeckel wrote: > Hi, > > I have a branch on my Github fork to support object library linking: > > object-library-linking > https://github.com/mathstuf/CMake/tree/object-library-linking >
Thanks for working on this. > There is also a commit which updates usage of $<TARGET_OBJECTS> to not > be allowed in IMPORTED targets. This would likely require a policy > unless anyone can think of a use case for allowing it (or just do "no > worse" than previous versions and just let it be). Is there a reason to disallow that? We might guess it will be possible to install object libraries in the future. > add_library(a INTERFACE) > target_sources(a INTERFACE sym1.c) > target_include_directories(a INTERFACE some/path/for/sym1) > target_compile_definitions(a INTERFACE CLIENT_DEFINE) > > add_library(b SHARED shared.c) > target_link_libraries(b PUBLIC a) # Needs CLIENT_DEFINE and to > # propagate the include > > add_executable(exe main.c) > target_link_libraries(exe b) Can you imagine a reason for both 'b' and 'exe' need sym1.c? Or do you imagine it to be something that should be only compiled into the shared library or only the executable? In other words - Is the buildsystem description above buggy? I had imagined other cases which were easy to reason about (and probably more common to need) such as: target_sources(a INTERFACE $<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,EXECUTABLE>sym1.c> ) So that it would just 'pass through' any intermediate libraries. > The real fix is to make INTERFACE_SOURCES only applicable when > directly linked and not transitive, but that is a bigger change. Would it make sense to uniq all sources? Or only uniq the ones which come from the link interface? I would prefer to see 'linking to' an object library consume its sources directly without needing to specify the target in both the sources and the target_link_libraries. 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
