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

[Ben Boeckel]

On Tue, Feb 24, 2015 at 23:25:20 +0100, Stephen Kelly wrote:
> Brad King wrote:
> > Some restrictions are there because we cannot safely evaluate the
> > $<TARGET_OBJECTS> in general for all generators.  See the code
> > using EvaluateForBuildsystem.
> 
> TARGET_OBJECTS already may not be used by add_custom_{command,target}, 
> because cmake does not portably know the path to the object files.
> 
>  http://public.kitware.com/Bug/view.php?id=15226
> 
> If you want to lift that restriction for Makefile|Ninja generators and non-
> portable buildsystems, we can discuss that in a different thread. I think 
> it's probably a good idea.

OK, I'll just leave it with allowing OBJECT libraries to use the genex.
Further branches to address other usage can come later.

> Ben Boeckel wrote:
> > 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).
> 
> They're probably different enough to that that that mental model of them is 
> unhelpful.

So I think of it that way because my usual usage for them is to bring
source files from all over the place into a single library. The biggest
place is in VTK's Kit setup where each module is turned into an OBJECT
library and then used when the Kit library is defined (VTK uses
variables rather than usage requirements, so using target_link_libraries
was nothing more than "oh well, I'll use the variables" at the time.

> If you want to affect a particular downstream target, as opposed to a 
> category of downstreams, transitive usage requirements and putting something 
> like that in an INTERFACE are probably not the right tools.

As I said, tail-wagging-the-dog :) . Right now, I just need PRIVATE
usage, so there's no need for me to have this transitive interface
stuff, but in implementing it for PRIVATE, it's an issue I have to deal
with.

> It is just as easy to get into this situation when linking static libraries, 
> right? Object libraries are not part of the problem, right? Or could you 
> post a sscce?

It is, so maybe it's less of an issue. I just think it is much easier to
stumble upon it when you start throwing objects directly into link lines
implicitly rather than with a staticWithGlobalStatic -> {sharedA,
sharedB} -> exeUsingAandB setup.

> > 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...
> 
> Yes, that's possible by adding an ExclusiveList compatible type and 
> populating an appropriate property when linking to OBJECT libraries. I've 
> written a prototype and can clean it up and post it if that's part of the 
> solution.

As long as it is opt-in, I'm fine with this (it only really makes sense
in the presence of global statics with dtors).

> > Until that problem is solved we cannot make object libraries
> > implicitly offer their objects just through tll().
> 
> Honestly, the problem is still not clear to me. Is it something you would 
> want to write and expect to be correct, but which would actually be 
> incorrect? Is the static global object instance a necessary part of the 
> problem-scenario?

So this problem came up in a project where the current code uses LIBADD
in autotools. These added libraries are conditionally built and have
varying usage requirements (headers, linking, defines, etc.). Oh, they
also have symbols which need exporting. Removing the autotools
buildsystem altogether has been NAK'd already, so we're stuck with their
code layout or revamping the autotools (though even if that had been
done, the code probably still wouldn't get reorganized). Passing all of
the usage requirements around either in internal cache variables or
global properties (PARENT_SCOPE won't scale because I need to push
umpteen vars up 3 directories then inherit it into another) is less than
ideal.

Yes, I already tried using static libraries (I think $<LINK_ONLY> made
the duplicate symbols occur in dependent projects which use shared libs
through the transitive linking which then all went into an executable);
that's how I ended up trying object libraries.

--Ben