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 make
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
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
Steps to
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 handle
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:
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, too.
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.
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
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 our
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 ben.boec...@kitware.com wrote:
On Thu, Jul 16, 2015 at 13:27:12 -0400, David Cole via cmake-developers wrote:
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_property:
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
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
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:
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
On Fri, Jul 17, 2015 at 6:05 PM, David Cole dlrd...@aol.com 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
On Fri, Jul 17, 2015 at 11:50 AM, Brad King brad.k...@kitware.com 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
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
18 matches
Mail list logo
