Brad King brad.king@... writes:
Steve,
I think this may fall under your expertise now. The goal is to generate
a nice error message when an imported target's link interface depends on
other targets that should have been imported but have not been. Currently
we just get a build-time
On 04/24/2013 07:14 AM, Stephen Kelly wrote:
It's becoming conventional to use a namespace like NS:: for imported
targets. Would it be possible to assume that if linking to something which
has double colons, then it must be an imported target, and if we can't find
such an imported target, to
Brad King wrote:
For makefile generators and xcode it is not possible to use create
non-imported targets in a buildsystem. On Windows it doesn't seem to be
possible either (the : is mistaken for a drive delimiter). It does
currently work with Ninja though, so a policy may be needed if it's a
Brad King brad.king@... writes:
On 02/20/2013 03:57 PM, Alexander Neundorf wrote:
On Wednesday 20 February 2013, Brad King wrote:
Alex, does this do what you want?
Looks good.
But shouldn't the IMPORTED_LINK_DEPENDENT_LIBRARIES libs be also taken into
account ?
I think so, so
On 03/27/2013 08:54 AM, Stephen Kelly wrote:
Brad King brad.king@... writes:
the iface-SharedDeps list needs to be included in
IMPORTED_LINK_INTERFACE_TARGETS_≤CONFIG also.
The problem with this is that it will break working code. Not-found entries in
the LINK_DEPENDENT_LIBRARIES do not
Brad King wrote:
On 03/27/2013 08:54 AM, Stephen Kelly wrote:
Brad King brad.king@... writes:
the iface-SharedDeps list needs to be included in
IMPORTED_LINK_INTERFACE_TARGETS_≤CONFIG also.
The problem with this is that it will break working code. Not-found
entries in the
On 03/27/2013 09:32 AM, Stephen Kelly wrote:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/35578/focus=35666
All I know is that it doesn't seem to cause a build error for me when I
export a target with LINK_PUBLIC Qt5::Core LINK_PRIVATE Qt5::Script and then
have the
Brad King wrote:
The Qt5::Script entry in IMPORTED_LINK_DEPENDENT_LIBRARIES_CONFIG will
be skipped by cmComputeLinkInformation::AddSharedDepItem if it is not an
available target name because it is not a full path.
When generating the Qt5 imported targets if you know dependencies will
be in
On 03/27/2013 10:22 AM, Stephen Kelly wrote:
I'm also a bit confused though because the Qt CI system tests Qt modules in
their build-location. In that case, if there are which private dependencies
are not in a common directory, there should be a failure.
There are other ways the linker may
Brad King wrote:
I think what we need is for the cmTarget::LinkInterface structure
to have a new TargetNames member populated by ComputeLinkInterface
from a new INTERFACE_TARGET_DEPENDS property (better names?).
On export of the link interfaces the net collection of target names
that refer
On Wednesday 20 February 2013, Brad King wrote:
On 02/20/2013 03:44 AM, Stephen Kelly wrote:
Brad King wrote:
I think what we need is for the cmTarget::LinkInterface structure
to have a new TargetNames member populated by ComputeLinkInterface
from a new INTERFACE_TARGET_DEPENDS property
On 02/18/2013 08:23 AM, Brad King wrote:
Another approach is to just add an extra property to imported targets
that list their dependencies that are expected to be targets. If when
following the link interface out of that target and a library name is
not a target, check the extra property on
On Tuesday 19 February 2013, Brad King wrote:
On 02/18/2013 08:23 AM, Brad King wrote:
Another approach is to just add an extra property to imported targets
that list their dependencies that are expected to be targets. If when
following the link interface out of that target and a library
Steve,
I think this may fall under your expertise now. The goal is to generate
a nice error message when an imported target's link interface depends on
other targets that should have been imported but have not been. Currently
we just get a build-time link failure because the name is treated as
On 02/17/2013 10:26 AM, Alexander Neundorf wrote:
On Sunday 17 February 2013, Alexander Neundorf wrote:
On Sunday 17 February 2013, Brad King wrote:
to use a directory property and then have the generate-time check
look in the current directory and up. That will avoid problems with
On 02/17/2013 10:00 AM, Alexander Neundorf wrote:
On Sunday 17 February 2013, Brad King wrote:
Just to make sure I understand correctly, you're bringing up a use case
where an imported target's dependencies are not satisfied but it does
not matter when the imported target is not used by the
On Monday 18 February 2013, Brad King wrote:
On 02/17/2013 10:00 AM, Alexander Neundorf wrote:
On Sunday 17 February 2013, Brad King wrote:
Just to make sure I understand correctly, you're bringing up a use case
where an imported target's dependencies are not satisfied but it does
not
On 02/18/2013 12:33 PM, Alexander Neundorf wrote:
Or do we allow broken targets to exist (but not to be used)
Yes, this should be allowed IMO. The target import files are
effectively declarative and evaluation of dependencies should
be lazy.
It wasn't that long ago that we started supporting
On Monday 18 February 2013, Brad King wrote:
On 02/18/2013 12:33 PM, Alexander Neundorf wrote:
Or do we allow broken targets to exist (but not to be used)
Yes, this should be allowed IMO. The target import files are
effectively declarative and evaluation of dependencies should
be lazy.
On 02/18/2013 01:32 PM, Alexander Neundorf wrote:
On Monday 18 February 2013, Brad King wrote:
On 02/18/2013 12:33 PM, Alexander Neundorf wrote:
Or do we allow broken targets to exist (but not to be used)
Yes, this should be allowed IMO. The target import files are
effectively declarative
On 2/15/2013 5:54 PM, Alexander Neundorf wrote:
The thing is, if I generate an error at configure time if at the end of a
directory a target has been used but has not been defined, i.e. a target Foo
has been imported which links against a missing imported target, it would
still be possible
On Sunday 17 February 2013, Brad King wrote:
On 2/15/2013 5:54 PM, Alexander Neundorf wrote:
The thing is, if I generate an error at configure time if at the end of a
directory a target has been used but has not been defined, i.e. a target
Foo has been imported which links against a missing
On Sunday 17 February 2013, Alexander Neundorf wrote:
On Sunday 17 February 2013, Brad King wrote:
On 2/15/2013 5:54 PM, Alexander Neundorf wrote:
The thing is, if I generate an error at configure time if at the end of
a directory a target has been used but has not been defined, i.e. a
Hi,
I think I saw somewhere in one of the threads something about being able to
set target properties before the target has been defined.
Is this the case or did I misunderstand something ?
If it's the case, then I have a few questions regarding this.
Is this scheduled for 2.8.11 ?
What
On 02/15/2013 03:03 PM, Alexander Neundorf wrote:
I think I saw somewhere in one of the threads something about being able to
set target properties before the target has been defined.
Is this the case or did I misunderstand something ?
I don't remember that coming up. You may be mixing it
On Friday 15 February 2013, Brad King wrote:
On 02/15/2013 03:03 PM, Alexander Neundorf wrote:
I think I saw somewhere in one of the threads something about being able
to set target properties before the target has been defined.
Is this the case or did I misunderstand something ?
I
On 02/15/2013 04:37 PM, Alexander Neundorf wrote:
So is it possible to refer to not-yet-defined targets from tll(), and what
happens if they get not defined later on ?
This works at it always has. If the named item does not resolve to a
target name at generate time it is treated as a raw
On Friday 15 February 2013, Brad King wrote:
On 02/15/2013 04:37 PM, Alexander Neundorf wrote:
So is it possible to refer to not-yet-defined targets from tll(), and
what happens if they get not defined later on ?
This works at it always has. If the named item does not resolve to a
target
28 matches
Mail list logo
