Putting quotes in and then taking them out. Where do the quotes come
from? Is there another way to put paths with spaces into ninja?
Yes sounds strange, but atm I've no better idea, ninja adds the quotes
because it internally has a space separated list, see the link in my
comment in merge
One of my last changes was to replaces back slashes with slashes
exactly because of \../../ problems. Have you used cl and
recent next?
With cl and recent next:
* Our host tools (the host-tools folder) basically get rebuilt everytime
you run ninja, and -d explain suggests x86 is dirty and
On 11.06.2012 13:23, Amine Khaldi wrote:
Another thing I noticed while testing ReactOS is that we end up with
entries like e:\reactos\ntoskrnl\include/../mm/ARM3/miarm.h (for
example) in the .d files, and this triggers recompiles. If this /../
construct is eliminated (not that it's practically
On 12.06.2012 13:47, Amine Khaldi wrote:
One of my last changes was to replaces back slashes with slashes
exactly because of \../../ problems. Have you used cl and
recent next?
With cl and recent next:
* Our host tools (the host-tools folder) basically get rebuilt everytime
you run ninja, and
The gcc build issues are all fixed. Thanks !
The cl scenario for host-tools remains, I'm still getting entries like
C:/Program\ Files\ (x86)/Windows\
Kits/8.0/include/shared/ConcurrencySal.h and C:/Program\ Files\
(x86)/Windows\ Kits/8.0/include/shared/sal.h
Thank you for looking into the
On 12.06.2012 14:58, Amine Khaldi wrote:
The gcc build issues are all fixed. Thanks !
The cl scenario for host-tools remains, I'm still getting entries like
C:/Program\ Files\ (x86)/Windows\
Kits/8.0/include/shared/ConcurrencySal.h and C:/Program\ Files\
(x86)/Windows\
Have you also rebuild cmcldeps?
That was it. My VS generated solution didn't have cmcldeps listed among
the modules, so I only rebuilt cmake. I confirm it works.
Excellent work Peter, thanks.
Regards,
Amine.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
On 6/12/2012 5:27 AM, Peter Kümmel wrote:
Yes sounds strange, but atm I've no better idea, ninja adds the quotes
because it internally has a space separated list, see the link in my
comment in merge request:
https://github.com/martine/ninja/pull/324
This is the reason for the patch:
On 12.06.2012 15:37, Bill Hoffman wrote:
On 6/12/2012 5:27 AM, Peter Kümmel wrote:
Yes sounds strange, but atm I've no better idea, ninja adds the quotes
because it internally has a space separated list, see the link in my
comment in merge request:
https://github.com/martine/ninja/pull/324
On 6/12/2012 11:21 AM, Peter Kümmel wrote:
When you debug it, you will see that it is not that simple.
When the path is read you don't know what is done with it later on.
Where is it read? Seems like at that point it does not matter where it
is used later one. Once you read it in, it
On 12.06.2012 17:43, Bill Hoffman wrote:
On 6/12/2012 11:21 AM, Peter Kümmel wrote:
When you debug it, you will see that it is not that simple.
When the path is read you don't know what is done with it later on.
Where is it read? Seems like at that point it does not matter where it
is used
On 6/12/2012 11:21 AM, Peter Kümmel wrote:
When you debug it, you will see that it is not that simple.
When the path is read you don't know what is done with it later on.
And feeding fopen with is wrong anyway.
BTW, you can create files with in the name on Windows, just not from
explorer:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13294
==
Reported By:Matthias Kretz
Assigned To:
On 12.06.2012 18:07, Bill Hoffman wrote:
On 6/12/2012 11:21 AM, Peter Kümmel wrote:
When you debug it, you will see that it is not that simple.
When the path is read you don't know what is done with it later on.
And feeding fopen with is wrong anyway.
BTW, you can create files with in the
On 6/12/2012 1:22 PM, Peter Kümmel wrote:
Maybe you should use \ \ as build folder ;)
I agree, it is crazy Well, lets hope you can get them to accept your
changes upstream. One thing that might help is if you created a case
that failed on linux with spaces in the path. They seem to care
One more thing... Why is the MFC test failing now?
-Bill
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this
On 12.06.2012 19:27, Bill Hoffman wrote:
On 6/12/2012 1:22 PM, Peter Kümmel wrote:
Maybe you should use \ \ as build folder ;)
I agree, it is crazy Well, lets hope you can get them to accept your
changes upstream.
I found a much simpler patch:
On 6/12/2012 1:44 PM, Peter Kümmel wrote:
I found a much simpler patch:
https://github.com/syntheticpp/ninja/commit/0ea34053a4692f190b8c13ce0ff032a57cece047
Could you please have a look at it before I create a merge request?
I would change RemoveQuotes to only remove them if they are at
On 12.06.2012 19:59, Bill Hoffman wrote:
On 6/12/2012 1:44 PM, Peter Kümmel wrote:
I found a much simpler patch:
https://github.com/syntheticpp/ninja/commit/0ea34053a4692f190b8c13ce0ff032a57cece047
Could you please have a look at it before I create a merge request?
I would change
On 6/12/2012 2:30 PM, Peter Kümmel wrote:
OK, but we need to handle strings like this:
... \outlib.dir\outlib.c.obj.d
Peter
OK, so where does the .d get added? That seems like the problem. It
should not be adding a .d to the end of a quoted string.
--
Bill Hoffman
Kitware, Inc.
28
On 12.06.2012 20:54, Bill Hoffman wrote:
On 6/12/2012 2:30 PM, Peter Kümmel wrote:
OK, but we need to handle strings like this:
... \outlib.dir\outlib.c.obj.d
Peter
OK, so where does the .d get added? That seems like the problem. It
should not be adding a .d to the end of a quoted
On 12.06.2012 21:10, Peter Kümmel wrote:
On 12.06.2012 20:54, Bill Hoffman wrote:
On 6/12/2012 2:30 PM, Peter Kümmel wrote:
OK, but we need to handle strings like this:
... \outlib.dir\outlib.c.obj.d
Peter
OK, so where does the .d get added? That seems like the problem. It
should not be
On 6/12/2012 3:10 PM, Peter Kümmel wrote:
-- depfile = $out.d = c:\my
build\Utilities\KWIML\test\CMakeFiles\cmIML_test.dir\test.c.obj.d
Maybe this should be mentioned on the ninja mailing list. If this were
CMake, I would say that the should be stripped when $out is being
expanded. It
On 12.06.2012 21:17, Bill Hoffman wrote:
On 6/12/2012 3:10 PM, Peter Kümmel wrote:
-- depfile = $out.d = c:\my
build\Utilities\KWIML\test\CMakeFiles\cmIML_test.dir\test.c.obj.d
Maybe this should be mentioned on the ninja mailing list. If this were
CMake, I would say that the should be
On 6/12/2012 3:15 PM, Peter Kümmel wrote:
First its evaluates the variable out
https://github.com/syntheticpp/ninja/blob/master/src/eval_env.cc#L36
- c:\my build\Utilities\KWIML\test\CMakeFiles\cmIML_test.dir\test.c.obj
So, if this removed the quotes would it work:
On 06/08/2012 12:59 PM, Stephen Kelly wrote:
Fixed now (I hope), thanks,
This change is now in master in preparation for 2.8.9.
Thanks for your work and persistence on this!
FYI, I rewrote the topic history prior to merging to clean up
all the cruft from dashboard fixes and the change in
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13295
==
Reported By:Sune Vuorela
Assigned To:
On Mon, Jun 11, 2012 at 6:53 PM, Peter Kümmel syntheti...@gmx.net wrote:
On 11.06.2012 18:02, David Cole wrote:
In 'next' we are seeing dashboard test failures (and I am seeing it on my
local build too, of course) that are related
to recent edits in Source/cmNinjaTargetGenerator.**cxx.
On 12.06.2012 21:30, Bill Hoffman wrote:
On 6/12/2012 3:15 PM, Peter Kümmel wrote:
First its evaluates the variable out
https://github.com/syntheticpp/ninja/blob/master/src/eval_env.cc#L36
- c:\my build\Utilities\KWIML\test\CMakeFiles\cmIML_test.dir\test.c.obj
So, if this removed the
On 12.06.2012 19:28, Bill Hoffman wrote:
One more thing... Why is the MFC test failing now?
Was a bug. rc files were compiled with cl.
-Bill
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages
On 13.06.2012 01:04, David Cole wrote:
If we want to increase the line length limitation, then we should discuss it
and come to a reasonable consensus.
We have reasons for wanting to keep the line length short, and we realize it's
not always comfortable. But it really
helps out viewing diffs
Hi,
I'm trying to use cmake to build c# files, on a linux box using mono.
I've got it pretty much working, but I can't figure how how to bundle
dependencies between libraries.
Basically, the builder does this:
- Create a fake builder library with the real build command (using gcs)
- Create a
On 12 June 2012 00:21, Ben Medina ben.med...@gmail.com wrote:
Has anyone tried the Visual Studio 2012 beta with CMake's Visual
Studio 11 generator? I've tried with several projects, and even a
simple project that just contains main.cpp has the same problem:
compiling a single file does not
Hi David,
thanks for your idea with REQUIRED_FILES. I don't like the way, but
we'll evaluate if it is enough for our project.
Maybe a proper solution will be included in a future release of CMake.
Bye
Christoph
There is a test property called REQUIRED_FILES, which is a list of files
that
On 06/11/2012 07:21 PM, Ben Medina wrote:
Has anyone tried the Visual Studio 2012 beta with CMake's Visual
Studio 11 generator? I've tried with several projects, and even a
simple project that just contains main.cpp has the same problem:
compiling a single file does not work. Instead, I get
The regex check for version of java does not find the version.
My system reports java -version as:
java version 1.7.0_b147-icedtea
I changed line 110-113:
IF(var MATCHES java version \[0-9]+\\.[0-9]+\\.[0-9_.]+[oem-]*\.*)
# This is most likely Sun / OpenJDK, or maybe
On Mon, Jun 11, 2012 at 7:21 PM, Ben Medina ben.med...@gmail.com wrote:
Has anyone tried the Visual Studio 2012 beta with CMake's Visual Studio 11
generator?
I just installed the VS 2012 RC from MSDN:
Microsoft Visual Studio Professional 2012 RC Version 11.0.50522.1 RCREL
Microsoft .NET
Yes, manually editing the hand-generated (well, project wizard
generated) file to use full paths triggers the problem. I guess I'll
report this to Microsoft, but it would be nice to confirm that others
are having the same problem.
- Ben
On Tue, Jun 12, 2012 at 5:19 AM, Brad King
Thanks for checking. Full project builds work fine for me; it's just
individual file compilations in the IDE that fail.
- Ben
On Tue, Jun 12, 2012 at 8:40 AM, Brad King brad.k...@kitware.com wrote:
On Mon, Jun 11, 2012 at 7:21 PM, Ben Medina ben.med...@gmail.com wrote:
Has anyone tried the
Thanks for the suggestion. Unfortunately, CMAKE_USE_RELATIVE_PATHS
seems to have no effect for this generator.
- Ben
On Tue, Jun 12, 2012 at 2:21 AM, Brett Delle Grazie
brett.dellegra...@gmail.com wrote:
On 12 June 2012 00:21, Ben Medina ben.med...@gmail.com wrote:
Has anyone tried the Visual
On 06/12/2012 11:43 AM, Ben Medina wrote:
Thanks for checking. Full project builds work fine for me; it's just
individual file compilations in the IDE that fail.
Okay. My initial read of your original message made it sound like
you got the error for any project even if it is only one file.
On 06/12/2012 11:51 AM, Brad King wrote:
http://www.cmake.org/Bug/view.php?id=12570
The main change to address it is here:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d931ce9f
I forgot to point out that this change is not in CMake 2.8.8
but will be in 2.8.9.
-Brad
--
Powered by
Hi,
We are adding some resource files (XML files, shaders, etc.) to a Visual
Studio project just to make them visible and accessible in the IDE.
We also add geometry files with the extension obj. Visual Studio treats
these as regular object files and starts using them during the build.
Is
On 06/12/2012 11:51 AM, Brad King wrote:
http://www.cmake.org/Bug/view.php?id=12570
The main change to address it is here:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d931ce9f
The problem was known to occur for VS 10 but did not in the
VS 11 developer preview. Perhaps it has
On 6/12/2012 1:10 PM, Daniel Dekkers wrote:
Hi,
We are adding some resource files (XML files, shaders, etc.) to a Visual
Studio project just to make them visible and accessible in the IDE.
We also add geometry files with the extension “obj”. Visual Studio
treats these as regular object files
Are there any errors or warnings reported in the full output stream?
Is there output indicating that libPipelineBuilderLib.dylib is being
fixed up at some point?
Is it possible that something is
overwriting/re-copying libPipelineBuilderLib.dylib after it's been fixed up?
On Mon, Jun 11, 2012
Funny, I just got to looking at this again. I ended up just blowing away the
build directory and recompiling and now it all works as it should. To answer
your questions though:
The output stated that libPipelineBuilder.dylib was being fixed up.
I was running a script that moved some stuff
No problem. I just ask questions when there's not enough information... and
when I get lucky: things fix themselves. :-)
On Tue, Jun 12, 2012 at 1:43 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
Funny, I just got to looking at this again. I ended up just blowing away
the build
Thanks! Here are the results:
- Using the VS2010 generator, the project files have relative paths.
VS2012RC can load 2010 project files without modifying them. If I do
this, compilation of individual files is successful.
- Using the VS11 generator, the project files have absolute paths, and
Ok, great, works.
So I guess the little red stop-sign icons shown by Visual Studio denote that
these files are excluded from the build?
Thanks,
Daniel
-Oorspronkelijk bericht-
Van: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] Namens Bill
Hoffman
Verzonden: dinsdag 12 juni
Hi Folks,
Currently the documentation associated with set command is the following:
[...]
FILEPATH = File chooser dialog.
PATH = Directory chooser dialog.
STRING = Arbitrary string.
BOOL = Boolean ON/OFF checkbox.
INTERNAL = No GUI
I've filed a bug with Microsoft:
https://connect.microsoft.com/VisualStudio/feedback/details/748640/cannot-compile-individual-files-if-project-contains-full-path-to-file
On Tue, Jun 12, 2012 at 11:20 AM, Ben Medina ben.med...@gmail.com wrote:
Thanks! Here are the results:
- Using the VS2010
Yeah - I can reproduce this too (better late than never - sorry!) I've
upvoted your bug report Ben.
Cheers,
Fraser.
On 12/06/2012 19:55, Ben Medina wrote:
I've filed a bug with Microsoft:
Thanks, Fraser! Note that the sample project I attached may take a
few hours to appear publicly, according to their bug report page.
And I apologize: everywhere I mention VS2012 beta in the above thread,
I meant VS2012 RC.
On Tue, Jun 12, 2012 at 12:02 PM, Fraser Hutchison
On 06/12/2012 02:55 PM, Ben Medina wrote:
I've filed a bug with Microsoft:
https://connect.microsoft.com/VisualStudio/feedback/details/748640/cannot-compile-individual-files-if-project-contains-full-path-to-file
Fantastic, thanks!
-Brad
--
Powered by www.kitware.com
Visit other Kitware
On 06/12/2012 02:20 PM, Ben Medina wrote:
- Using the VS2010 generator, the project files have relative paths.
VS2012RC can load 2010 project files without modifying them. If I do
this, compilation of individual files is successful.
- Using the VS11 generator, the project files have absolute
Hi,
I have a folder in which I build a library. For doing so I have a
add_definitions(-DMySymbol) line
It seems that subfolders inherits this,which I don't want. How do I undef the
MySymbol symbol in a subfolder CMakeList file?
-totte
--
.
Totte Karlsson, Ph.D.
Dune
Seem
that add_definitions(/UTheSymbol) did the job!
-totte
On 6/12/2012 2:57 PM, Totte Karlsson wrote:
Hi,
I have a folder in which I build a library. For doing so I have a
add_definitions(-DMySymbol) line
It seems that subfolders inherits this,which I don't want. How do I undef the
MySymbol
Hi,
I have a CMakeLists.txt that creates both a shared and static lib.
In short it looks something like this:
add_definitions(-DEXPORT_RR)
add_library(${target} SHARED ${rrSources})
add_library(${target}-staticSTATIC ${rrSources})
The problem being that for the static version,
Please do not use anything except for -D args with add_definitions. Other
flags should be added to CMAKE_CXX_FLAGS or some other variable, and they
are compiler specific. I doubt that /U works uniformly across compilers
the same way -D does.
The remove_definitions command is the opposite of the
Hi,
For a certain library, I changed my CMake file to using the following
install (
TARGETS ${target}
RUNTIME DESTINATION bin
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib
COMPONENT c_api)
It works fine installing, but when running
On 6/12/2012 3:55 PM, David Cole wrote:
Please do not use anything except for -D args with add_definitions. Other flags
should be added to CMAKE_CXX_FLAGS or some other variable, and they are compiler
specific. I doubt that /U works uniformly across compilers the same way -D
does.
Yeah, it
You can use:
set_target_properties(${target}-static PROPERTIES
COMPILE_DEFINITIONS RR_STATIC)
For full details, run:
cmake --help-property COMPILE_DEFINITIONS
Cheers,
Fraser.
On 12/06/2012 23:39, Totte Karlsson
wrote:
On 6/12/2012 4:23 PM, Fraser Hutchison wrote:
You can use:
|set_target_properties(${target}-static PROPERTIES COMPILE_DEFINITIONS
RR_STATIC)|
I got the following tip from D Cole to use
set_property(TARGET ${target}-static PROPERTY COMPILE_DEFINITIONS RR_STATIC)
I assume
I assume they do the same thing too in this case, but I defer to David
since he works for Kitware and knows the source code, whereas I don't
and don't :-)
On 13/06/2012 00:56, Totte Karlsson wrote:
On 6/12/2012 4:23 PM, Fraser Hutchison wrote:
You can use:
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 85f2622eba565024a15e20b9e0abe07a2240530f (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 9ee3fd68e754d396c99f732714efa7ed1bbe845a (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 ed157fcd3830ac139ec8983e4f72fe60aab7cce8 (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 a8fa345ea2361a6018a0dc62c3380397b1c2c5f9 (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 d6483cb542b91bb9297125cdaf9017fd8785ccd3 (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 e21bcdc6c657ac223d95c0ae92eb398e1659763d (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 4075e1ca6ccd01183c9bb582a2291c5abc70a828 (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 2b3b45aec9f825edd42eb02aed5451ee96c182cc (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 daf552e3edaf65e4fae3817d74dae8fa584e4bae (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 f848dbfe3ce57790bf4974cc2d142196228427f5 (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 909ddae2e45823d4a005ddf207cdf4421a08965d (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 9297ccff9bf6fc0c7b650c6ee1088ad03a8b3994 (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 6a52f3cb36ed1c1ff1a8ec26a19fb36665f8baa8 (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 c6f6929e31a3e8067633aa57cf0775bced9d8443 (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 c95d1baa194c8108841a8b973d3bbe50ca7d5666 (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 bc5177b99e86e2f30926bbb183479a233dc4b544 (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 77f471b8405f93d8f56c4b5f4e31642d9f49 (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 9267a6a1cdeea5b8847c903e114334280d6bb90c (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 54449c11d0b779b62178e71136cc013771078931 (commit)
via
Stamp
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 345a56f..b042e0c 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 8)
-SET(CMake_VERSION_TWEAK 20120612
85 matches
Mail list logo
