Re: [cmake-developers] Branches on next

2014-02-11 Thread Ben Boeckel
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 a

Re: [cmake-developers] Branches on next

2014-02-11 Thread Matthew Woehlke
On 2014-02-11 17:54, Ben Boeckel wrote: 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_parsi

[cmake-developers] AddCustomCommandWithConfig

2014-02-11 Thread Steve Wilson
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 http://www.

Re: [cmake-developers] add_custom_command differences in tests

2014-02-11 Thread Steve Wilson
Thank you, that fixed the problem I was seeing. SteveW On Feb 10, 2014, at 8:28 AM, Brad King 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 my test call

Re: [cmake-developers] Branches on next

2014-02-11 Thread Ben Boeckel
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. > https://github.com/mwo

Re: [cmake-developers] dev/custom-parsers topic (was: Branches on next)

2014-02-11 Thread Ben Boeckel
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? < in-person discussion of the algorithm > After looking at the implementation, it may not save much since we

Re: [cmake-developers] Branches on next

2014-02-11 Thread Matthew Woehlke
On 2014-02-11 14:49, Ben Boeckel wrote: 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

Re: [cmake-developers] push of LinkOptionsCommand topic branch

2014-02-11 Thread Steve Wilson
On Feb 8, 2014, at 4:10 AM, Stephen Kelly 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 comparable to this, wh

Re: [cmake-developers] dev/custom-parsers topic (was: Branches on next)

2014-02-11 Thread Ben Boeckel
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 close

Re: [cmake-developers] dev/custom-parsers topic (was: Branches on next)

2014-02-11 Thread Brad King
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

[cmake-developers] Branches on next

2014-02-11 Thread Ben Boeckel
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 an

Re: [cmake-developers] Backward compatbility code

2014-02-11 Thread Brad King
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 n

Re: [cmake-developers] Backward compatbility code

2014-02-11 Thread Brad King
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, t

Re: [cmake-developers] Backward compatbility code

2014-02-11 Thread Stephen Kelly
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 ex

Re: [cmake-developers] Backward compatbility code

2014-02-11 Thread Brad King
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

Re: [cmake-developers] Backward compatbility code

2014-02-11 Thread Stephen Kelly
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. >> >> An

[cmake-developers] [CMake 0014750]: Consider dropping Qt4 module dependency adding

2014-02-11 Thread Mantis Bug Tracker
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14750 == Reported By:Orion Poplawski Assigned To:

Re: [cmake-developers] ninja parallelism and LLVM cmake builds

2014-02-11 Thread Stephen Kelly
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

Re: [cmake-developers] ninja parallelism and LLVM cmake builds

2014-02-11 Thread Brad King
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: target

[cmake-developers] [CMake 0014749]: Control returned value by CTest

2014-02-11 Thread Mantis Bug Tracker
The following issue has been SUBMITTED. == http://cmake.org/Bug/view.php?id=14749 == Reported By:Mathieu Malaterre Assigned To:

Re: [cmake-developers] ninja parallelism and LLVM cmake builds

2014-02-11 Thread Stephen Kelly
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 expressi

Re: [cmake-developers] Backward compatbility code

2014-02-11 Thread Brad King
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 pol

Re: [cmake-developers] Invitation to connect on LinkedIn

2014-02-11 Thread Brad King
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 pro

Re: [cmake-developers] ninja parallelism and LLVM cmake builds

2014-02-11 Thread Brad King
On 02/10/2014 10:34 PM, Bill Hoffman wrote: > Someone just posted this comment to one of my blogs: > (http://www.kitware.com/blog/home/post/434) > >> I don’t know if CMake or Ninja (or LLVM’s build rules) are at fault >> here, but when I build Clang and LLVM under CMake and Ninja, parallelism >>

Re: [cmake-developers] Backward compatbility code

2014-02-11 Thread Stephen Kelly
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 >> @@ -16