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:
Hello,
#1. The cmake roadmap informs me that 100% of version 3.0 is complete. Any news
on when this will be released?
#2. How does the development team decide which issues are included in any given
release? As an example, I reported a feature request some months back
#1. The cmake roadmap informs me that 100% of version 3.0
is complete. Any news on when this will be released?
Soon:-)
(Although, disclaimer: I'm not responsible for it anymore, so I can't
be more precise than that...)
#2. How does the development team decide which issues
are
That's just the quick brain dump version. If necessary, I can
actually
look at old commits, or the current code to try to refresh my memory.
I think that's needed. Can you do that research into the commits and
discussion?
I know it's been a week now I'm still getting to this. Will
Should I file this as a bug in the issue tracker then?
Sure. Especially if you have an easy way to reproduce. (Either
reference an external, publicly available project we can just
build and get it to happen, or attach a CMakeLists that
demonstrates the issue if possible.)
That way, we can
Hi there,
The Makefile that cmake generates includes a rule to automatically re-run
cmake if any of the input CMakelists.txt files change.
Is there a way to configure this rule to have it run clean first?
Currently, if you change the name of an executable target (or library), it
will leave the
On 2014-02-12 11:35, Abe Bachrach wrote:
The Makefile that cmake generates includes a rule to automatically re-run
cmake if any of the input CMakelists.txt files change.
Currently, if you change the name of an executable target (or library), it
will leave the old file in the output location,
On Wed, Feb 12, 2014 at 8:53 AM, Matthew Woehlke
mw_tr...@users.sourceforge.net wrote:
What you really want is to record the old list of output files, re-run
CMake, then remove any files on that list that no longer have rules to
generate them. If you do a complete 'clean' you will delete and
Hi
I am trying to use the Ninja generator to compile on a Windows machine using
the Visual Studio 11 compilers.
From a VS11 console I run cmake (version: 2.8.11.2 ):
cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_SYSTEM_NAME=MSVC ..
I then run Ninja (version 1.4.0)
ninja -v
and all
On 2014-02-12 17:22- Dominic Walsh wrote:
Hi
I am trying to use the Ninja generator to compile on a Windows machine using
the Visual Studio 11 compilers.
From a VS11 console I run cmake (version: 2.8.11.2 ):
cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_SYSTEM_NAME=MSVC ..
I then
I am trying to set up component registration as per
http://www.cmake.org/Wiki/CMake/Tutorials/Packaging
but when I run Cmake I get the error
install TARGETS given unknown argument EXPORT.
While I've found many hits on Google with that error string, none that I
have found have any resolution
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 46c28dbc0be50e10c6d39b5066752eb9a0651949 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 764d467d24ca07eb6ebaad33be1c7f7f56294e8c (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 0d177cf383fbca1d23fcd57672683d66c403d738 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via e6f0b870fd69206d9e7848a07135dde809beddc2 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 9cdbfc8deb6e3431be67fefb6007931c9b4c7872 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 3c64f7fe7a468d5b497df9694f6c00a6c68bc189 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 85c864253322b4d79d854e960239ae2a93705242 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 6bfa75bcf843e512a18a28063fa8a6edd1633572 (commit)
via
Stamp
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 4bbbd75..c3a319a 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -2,5 +2,5 @@
set(CMake_VERSION_MAJOR 2)
set(CMake_VERSION_MINOR 8)
set(CMake_VERSION_PATCH 12)
-set(CMake_VERSION_TWEAK 20140212
37 matches
Mail list logo
