[cmake-developers] Object library linking (and a bit about INTERFACE_SOURCES)
Stephen Kelly
steveire at gmail.com
Mon Feb 23 15:05:01 EST 2015
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.
More information about the cmake-developers
mailing list