On Fri, Jul 17, 2015 at 6:05 PM, David Cole wrote:
> Attached is a patch file of my first attempt. I can iterate some more
> on this (better testing, add docs, clarify existing docs, address
> anybody's comments, submit to stage) next week. Attached now in case
> anybody wants to try it out over t
On Fri, Jul 17, 2015 at 11:50 AM, Brad King wrote:
> On 07/15/2015 10:38 PM, Clifford Yapp wrote:
>> Lists that contains a verbatim collection of all path specifiers,
>> regardless of form, that are passed to the various add_* targets would
>> be enough, I think - it'd then be up to our own CMake
Attached is a patch file of my first attempt. I can iterate some more
on this (better testing, add docs, clarify existing docs, address
anybody's comments, submit to stage) next week. Attached now in case
anybody wants to try it out over the weekend.
Cheers,
David C.
On Fri, Jul 17, 2015 at 3:0
I think the see also is relevant because it points to another way to
get to a whole different set of "properties". Perhaps what they're
looking for when they stumble upon get_cmake_property is actually
target properties, which are only accessible via get_property.
While it's relevant, and I think
On Fri, Jul 17, 2015 at 14:16:34 -0400, David Cole wrote:
> get_cmake_property is more like "strictly well-pre-defined, read only
> (ish), built-into CMake" properties. Note there is no
> set_cmake_property... What docs are you looking at that you think have
> a bug...?
Help/command/get_cmake_prop
I'm going to be away for a few weeks, is it ok if the master branch stays in
that state for a while?
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Friday, July 17, 2015 11:47 AM
To: Robert Goulet
Cc: Stephen Kelly; cmake-developers@cmake.org
Subject: Re: [cmake-
get_cmake_property is more like "strictly well-pre-defined, read only
(ish), built-into CMake" properties. Note there is no
set_cmake_property... What docs are you looking at that you think have
a bug...?
To implement TARGETS for get_cmake_property, I would look to see what
logic is used by "if(TA
On Fri, Jul 17, 2015 at 12:18:18 -0400, David Cole wrote:
> Are you saying there should be a named GLOBAL property with this
> information in it...?
>
> It seems like more of a fit to get_cmake_property.
Indeed. It seems there is no overlap between `get_property` and
`get_cmake_property`. Which m
> What is your actual use case for expanding this info during the configuration
process?
We feed our static lib and the list of its dependencies to the `libtool` to
create an amalgamated, standalone static library.
This is an iOS-specific issue: we need this because iOS doesn't support
shared libr
Are you saying there should be a named GLOBAL property with this
information in it...?
It seems like more of a fit to get_cmake_property.
On Fri, Jul 17, 2015 at 10:14 AM, Ben Boeckel wrote:
> On Thu, Jul 16, 2015 at 13:27:12 -0400, David Cole via cmake-developers wrote:
>> This would best be ad
On 07/15/2015 10:38 PM, Clifford Yapp wrote:
> Lists that contains a verbatim collection of all path specifiers,
> regardless of form, that are passed to the various add_* targets would
> be enough, I think - it'd then be up to our own CMake logic to make
> sense of it all. I'm not hoping to push
On 07/17/2015 10:55 AM, Robert Goulet wrote:
> Ok I'd like to fix the crash, what is the clean way to deal with
> this kind of situation? I'm guessing this might be a problem that
> was solved elsewhere for other cases before?
I don't recall other cases where this specific problem has come
up. Th
On 07/16/2015 11:29 AM, Tamás Kenéz wrote:
> Well, it seems that `BundleUtilities` can't expand a single static imported
> library target to the list of all dependent libraries (that's what I need)
> so I think `CMakeExpandImportedTargets` is still benefitial and could be
> benefitial to others, to
Ok I'd like to fix the crash, what is the clean way to deal with this kind of
situation? I'm guessing this might be a problem that was solved elsewhere for
other cases before?
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Friday, July 17, 2015 10:44 AM
To: Robe
On 07/15/2015 05:27 PM, Robert Goulet wrote:
> I didn't know about the two signature of
> cmCompiledGeneratorExpression::Evaluate, what's the difference?
>
> As for the TARGET_PROPERTY generator expression, are you suggesting
> this could potentially be an issue? I haven't tried it.
If cmCompiled
On 07/15/2015 05:08 PM, Michael Scott wrote:
> Looking at the cmMessageCommand::InitialPass and
> cmake::PrintMessagePreamble code, if we want to mirror the deprecation
> message behaviour, I'm tempted to suggest we also modify the message
> mode "AUTHOR_WARNING" to be "AUTHOR" instead. It would
On Thu, Jul 16, 2015 at 13:27:12 -0400, David Cole via cmake-developers wrote:
> This would best be added as a "TARGETS" variant of the existing
> http://www.cmake.org/cmake/help/v3.3/command/get_cmake_property.html
> command.
>
> (In my opinion...)
The get_property command would also need to han
>>>There is currently no way to exclude a component install() from a full
>>>installation. Current workarounds using OPTIONAL do not work reliably
because
>>>they depend on previous builds and on the order execution of the build
and
>>>install commands for the components and the default target
>>>
18 matches
Mail list logo
