[cmake-developers] Object library linking (and a bit about INTERFACE_SOURCES)

[Ben Boeckel]

On Mon, Feb 23, 2015 at 21:05:01 +0100, Stephen Kelly wrote:
> Is there a reason to disallow that? We might guess it will be possible to 
> install object libraries in the future.

We could also lift the restriction then. I'm fine with just dropping the
patch. Basically without it, all it blocks is
add_custom_{command,target} from using $<TARGET_OBJECTS>…which could be
useful for some obscure linker target CMake doesn't understand. So maybe
just lifting all such restrictions on $<TARGET_OBJECTS> is the thing to
do.

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

Sure, I *can*, but it's also not how I've used object libraries so far
(basically as static libraries I don't need to export). And now I'd like
to use usage requirements to make things easier (rather than setting
global properties and fetching them from nowhere later in the code).

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

That works for that case, but doesn't work when it needs to land in a
specific shared or static library (though I suppose STREQUAL +
TARGET_NAME could work there too, but that doesn't feel clean to me and
also feels like the tail wagging the dog).

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

Well, they'd still be unique at the usage location, but already be
linked into some library lower in the depchain (except in the diamond
usage scenario where dedup would help at the join part, but not help
that there are now 3 copies of symbols around).

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

I would as well, but with transitive linking, getting duplicate
symbols/static variables is way too easy at the moment (and debugging
the latter is not always easy if you don't know what you're looking
for). If you know what you're doing you can set target_sources on the
object library without issue as it is. I just don't think we should
throw landmines in front of unsuspecting developers who use this.

For the diamond-usage problem, is there some way of utilizing the
COMPATIBLE_INTERFACES to deny the mixing of two libraries where each
built with an object libraries' objects? Having a property to trigger
that would be nice...

--Ben