The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14751
==
Reported By:Stephen Kelly
Assigned To:
Steve Wilson wrote:
when I do the checkout followed by the reset —hard,
all I get is the same set of commits that I had before.
What makes you conclude they are the same?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
Steve Wilson wrote:
I just pushed the topic AddCustomCommandWithConfig to stage. This topic
implements the CONFIG keyword for add_custom_command().
I haven't looked thoroughly, but how much does dependency
specification/handling need to change? The dependency of a command on a set
of
On 02/12/2014 04:15 AM, Stephen Kelly wrote:
I haven't looked thoroughly, but how much does dependency
specification/handling need to change? The dependency of a command on a set
of targets should now be config-specific, right?
I haven't read through the topic yet but IIRC we discussed the
On 2014-02-11 23:03, Ben Boeckel wrote:
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
On Tue, Feb 11, 2014 at 14:49:42 -0500, Ben Boeckel wrote:
(though Makefiles generate faster than the configure for
ParaView) and minimal for Ninja).
I've addressed this…at least 2x speedup of Ninja's generate time in
ParaView (2.8.12.2: 95 seconds; branch with *all* performance
On 2014-02-11 23:03, Ben Boeckel wrote:
On Tue, Feb 11, 2014 at 19:16:49 -0500, Matthew Woehlke wrote:
On 2014-02-11 17:54, Ben Boeckel wrote:
ExpandVariablesInString is the part which takes a string which may have
variables in it and dereferences them.
Yes, that's why your changes are
I saved a copy of the branch in another of the repository. The commit numbers
didn’t change and as far as I can tell they are still in the same order that I
had them in when I initially pushed the branch.There are no rebases
removing the downstream updates, etc...
On Feb 12, 2014, at
Steve Wilson wrote:
I saved a copy of the branch in another of the repository. The commit
numbers didn’t change and as far as I can tell they are still in the same
order that I had them in when I initially pushed the branch.There are
no rebases removing the downstream updates, etc...
On Feb 12, 2014, at 2:15 AM, Stephen Kelly steve...@gmail.com wrote:
I haven't looked thoroughly, but how much does dependency
specification/handling need to change? The dependency of a command on a set
of targets should now be config-specific, right? Does that mean making
changes to
On Wed, Feb 12, 2014 at 11:46:39 -0500, Matthew Woehlke wrote:
That code isn't even on the radar for expensive code. It probably could
be replaced with smaller code other than lex/yacc, but it's not worth
the time if performance is the goal (removing lines, however…). Anything
other than
On 02/12/2014 08:40 AM, Brad King wrote:
On 02/12/2014 04:15 AM, Stephen Kelly wrote:
I haven't looked thoroughly, but how much does dependency
specification/handling need to change? The dependency of a command on a set
of targets should now be config-specific, right?
I haven't read
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14752
==
Reported By:N. Thompson
Assigned To:
On Wed, Feb 12, 2014 at 11:42:53 -0500, Ben Boeckel wrote:
I've addressed this…at least 2x speedup of Ninja's generate time in
ParaView (2.8.12.2: 95 seconds; branch with *all* performance changes:
40 seconds; something like 55 with just the Ninja changes). It will show
up on the stage in a
Hi Eike,
all right, then Hg, as it's FindHg, unless there is a naming policy I'm
not aware of. I was just confused a bit due to FindGit, which uses GIT_
as the prefix.
How do I proceed from here? What should I do next?
Cheers,
Matthäus
On 08.02.2014 17:38, Rolf Eike Beer wrote:
Am Samstag,
Given the complicated nature of FindBoost and it's many many use cases, I'd
like to run this by the list for inclusion in to the FindBoost.cmake
module. First let me preface this with the note that this patch maintains
100% backwards compatibility and will default to the current behaviour.
That
On Tue, Feb 11, 2014 at 19:16:49 -0500, Matthew Woehlke wrote:
If you're looking for corner-cases, check out the RunCMake.Syntax test
in the source tree. If you can handle that, you're probably doing pretty
well on the basics.
Thanks; I may do that some time.
Also look at
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14753
==
Reported By:Dmiry Marakasov
Assigned To:
18 matches
Mail list logo
