On 02/24/2015 05:25 PM, Stephen Kelly wrote:
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.
Consider an object library with some usage requirements:
add_library(objlib OBJECT
On Mon, Feb 23, 2015 at 13:44:13 -0500, Ben Boeckel wrote:
snip
After discussion with Brad here, the current, tentative, plan is as
follows:
- When creating $LINK_ONLY generator expressions, if the name is a
target, add $TARGET_NAME as well. This will help the exporter find
targets
Brad King wrote:
On 02/24/2015 05:25 PM, Stephen Kelly wrote:
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.
Consider an object library with some usage requirements:
Ben Boeckel wrote:
On Wed, Feb 25, 2015 at 22:57:13 +0100, Stephen Kelly wrote:
What I envision for the future is:
add_library(objlib OBJECT ...)
target_compile_definitions(objlib PUBLIC MYDEF)
target_sources(objlib INTERFACE $TARGET_OBJECTS:objlib)
Do you envision that as the
On Wed, Feb 25, 2015 at 22:57:13 +0100, Stephen Kelly wrote:
What I envision for the future is:
add_library(objlib OBJECT ...)
target_compile_definitions(objlib PUBLIC MYDEF)
target_sources(objlib INTERFACE $TARGET_OBJECTS:objlib)
Do you envision that as the idiomatic way to
Ben Boeckel wrote:
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
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
Stephen Kelly wrote:
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
Brad King wrote:
On 02/23/2015 07:50 PM, Ben Boeckel wrote:
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
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
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
11 matches
Mail list logo
