Brad King wrote:
On 02/10/2014 03:41 AM, Stephen Kelly wrote:
diff --git a/Source/cmAddCustomCommandCommand.cxx
b/Source/cmAddCustomCommandCommand.cxx
index 5634849..e967e3c 100644
--- a/Source/cmAddCustomCommandCommand.cxx
+++ b/Source/cmAddCustomCommandCommand.cxx
@@ -164,6 +164,7
On 02/11/2014 02:37 AM, Jayesh PATEL wrote:
I'd like to include you in my network to share updates and stay in touch.
http://community.linkedin.com/questions/19313/how-do-i-stop-linkedin-sending-out-invitation-emai.html
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source
On 02/11/2014 07:16 AM, Stephen Kelly wrote:
Ok, I'm not sure how to handle these two items. I've never used the SOURCE
signature of add_custom_command, and the AddCustomCommandOldStyle method
seems to also relate to things I haven't used before, so I wouldn't know how
to explain the
Brad King wrote:
target_link_libraries(staticB INTERFACE staticA)
However, that will propagate all usage requirements of A to consumers
of B. Depending on the usage requirements specified for A and B that
may be correct or not.
We could consider making the LINK_ONLY generator expression
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=14749
==
Reported By:Mathieu Malaterre
Assigned To:
On 02/11/2014 08:46 AM, Stephen Kelly wrote:
We could consider making the LINK_ONLY generator expression public in order
to allow the user to decide the granularity here (possibly encapsulated in a
INTERFACE_LIBRARY).
For reference, without the interface target it is as simple as:
Brad King wrote:
On 02/11/2014 08:46 AM, Stephen Kelly wrote:
We could consider making the LINK_ONLY generator expression public in
order to allow the user to decide the granularity here (possibly
encapsulated in a INTERFACE_LIBRARY).
For reference, without the interface target it is as
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14750
==
Reported By:Orion Poplawski
Assigned To:
Brad King wrote:
// For backwards compatibility replace varibles in source names.
- // This should eventually be removed.
+ // TODO: This should eventually be removed.
this-Makefile-ExpandVariablesInString(src);
A policy should be added to remove this behavior.
Any idea how to unit test
On 02/11/2014 11:48 AM, Stephen Kelly wrote:
Confirmed. I added CMP0049 to control this behavior.
Great.
Please include a Help/release/dev/backward-compatibility.rst
file with the relevant release note.
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
Brad King wrote:
On 02/11/2014 11:48 AM, Stephen Kelly wrote:
Confirmed. I added CMP0049 to control this behavior.
Great.
Please include a Help/release/dev/backward-compatibility.rst
file with the relevant release note.
Will this make it into 3.0.0? Should I just add it to the existing
On 02/11/2014 12:00 PM, Stephen Kelly wrote:
Will this make it into 3.0.0?
Likely, since it is in the spirit of the other legacy cleanup
policies. If not we can always bump the policy version before
final integration.
Should I just add it to the existing release notes on master if so?
No,
On 02/11/2014 01:18 PM, Brad King wrote:
On 02/11/2014 12:00 PM, Stephen Kelly wrote:
Should I just add it to the existing release notes on master if so?
No, thanks. I'd like to get everyone in the habbit of adding
notes to the dev/ files and myself in the habbit of integrating
the notes.
Hi,
I've just pushed two branches into next:
dev/custom-parsers
Replaces the parsers in cmMakefile::ExpandVariablesInString with
custom code rather than lex/yacc. The parsers in
cmGeneratorExpression::StripEmptyListElements
cmSystemTools::ExpandListArguments
On 02/11/2014 02:49 PM, Ben Boeckel wrote:
dev/custom-parsers
cmMakefile::ExpandVariablesInString has long been ripe for
optimization. Thanks for working on it.
Why does each level in the openstack need to hold its lookup
member? Can't everything be stored in-place in the work buffer?
Each
On Tue, Feb 11, 2014 at 15:54:40 -0500, Brad King wrote:
Why does each level in the openstack need to hold its lookup
member? Can't everything be stored in-place in the work buffer?
Each openstack level just needs to track the start character in
the work buffer. When that level is closed the
On Feb 8, 2014, at 4:10 AM, Stephen Kelly steve...@gmail.com wrote:
Great, thanks for all of that. I have force-pushed your branch, which means
you need to do this before proceeding with further work.
1) Get remote changes, including my change to your branch.
You'll see output
On Tue, Feb 11, 2014 at 17:18:22 -0500, Matthew Woehlke wrote:
On a loosely related note, did you know that there are now at least
two Python parsers for CMake script? (Besides I believe a C++ one in
KDevelop...)
1. https://github.com/ijt/cmakelists_parsing
2.
Thank you, that fixed the problem I was seeing.
SteveW
On Feb 10, 2014, at 8:28 AM, Brad King brad.k...@kitware.com wrote:
On 02/07/2014 05:19 PM, Steve Wilson wrote:
On Feb 7, 2014, at 3:01 PM, Brad King wrote:
-DCMAKE_BUILD_TYPE=\${CTEST_CONFIGURATION_TYPE}
I have tried adding that to
I just pushed the topic AddCustomCommandWithConfig to stage. This topic
implements the CONFIG keyword for add_custom_command().
SteveW
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
On Tue, Feb 11, 2014 at 19:16:49 -0500, Matthew Woehlke wrote:
On 2014-02-11 17:54, Ben Boeckel wrote:
Parsing in CMake is split into separate sections: the part which parses
the lines into CMake's command calls and the part which expands
variables (which is why ${cmd}(${args}) isn't allowed).
21 matches
Mail list logo
