On 6/12/2012 7:08 PM, Peter Kümmel wrote:
So we don't need any ninja patches, neither for msvc nor for mingw.
All tests pass with ninja master.
WOW!
Congrats, this is awesome. The windows ninja dashboard is totally green
today. Thanks for all the hard work, this is really great stuff.
On 6/13/2012 9:31 AM, Amine Khaldi wrote:
Please don't consider Windows as done until proper dependency tracking
is in place (it's lacking so far for rc files).
OK, so we need a test for rc file depend tracking. I did not realize
that was still missing. We have it for c/c++ now. I am
On 13.06.2012 15:16, Bill Hoffman wrote:
On 6/12/2012 7:08 PM, Peter Kümmel wrote:
So we don't need any ninja patches, neither for msvc nor for mingw.
All tests pass with ninja master.
WOW!
Congrats, this is awesome. The windows ninja dashboard is totally green
today. Thanks for all the
On Wed, Jun 13, 2012 at 05:34:14PM +0200, Peter Kümmel wrote:
On 13.06.2012 15:31, Amine Khaldi wrote:
Please don't consider Windows as done until proper dependency tracking
is in place (it's lacking so far for rc files).
Please test stage. I've added rc file dependency tracking.
It's a
On 13.06.2012 18:09, Peter Collingbourne wrote:
On Wed, Jun 13, 2012 at 05:34:14PM +0200, Peter Kümmel wrote:
On 13.06.2012 15:31, Amine Khaldi wrote:
Please don't consider Windows as done until proper dependency tracking
is in place (it's lacking so far for rc files).
Please test stage.
On 6/13/2012 12:41 PM, Peter Kümmel wrote:
Yes, this looks like a more advanced solution.
We only need to extract #line 1234 c:\... from the generated file.
Peter
--
Just do this:
cl /P /showIncludes
Then it won't error out, and will show the includes in the same format.
-Bill
--
On 13.06.2012 18:53, Bill Hoffman wrote:
On 6/13/2012 12:41 PM, Peter Kümmel wrote:
Yes, this looks like a more advanced solution.
We only need to extract #line 1234 c:\... from the generated file.
Peter
--
Just do this:
cl /P /showIncludes
Then it won't error out, and will show the
On Wed, Jun 13, 2012 at 1:20 PM, Peter Kümmel syntheti...@gmx.net wrote:
On 13.06.2012 18:53, Bill Hoffman wrote:
On 6/13/2012 12:41 PM, Peter Kümmel wrote:
Yes, this looks like a more advanced solution.
We only need to extract #line 1234 c:\... from the generated file.
Peter
--
Just
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:
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 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
Hi,
I just tested this with ReactOS and the results are really promising !
Thank you Peter for working on this.
One thing I noticed is the lack of dependency tracking for the resource
files (*.rc, they are compiled with rc and not cl). If you #include a
file in an .rc and then alter that
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 possible, I did it
just for testing) the
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
All tests pass now for MSVC and MinGW!
With some small patches for ninja:
https://github.com/syntheticpp/ninja/commits/ninja-for-cmake
The changes are only needed for msvc when the build
dir path contains spaces, and for mingw because of slashes
in path names.
Cheers,
Peter
--
Powered by
On 6/11/2012 10:21 PM, Peter Kümmel wrote:
All tests pass now for MSVC and MinGW!
With some small patches for ninja:
https://github.com/syntheticpp/ninja/commits/ninja-for-cmake
The changes are only needed for msvc when the build
dir path contains spaces, and for mingw because of slashes
in
On 12.06.2012 04:33, Bill Hoffman wrote:
On 6/11/2012 10:21 PM, Peter Kümmel wrote:
All tests pass now for MSVC and MinGW!
With some small patches for ninja:
https://github.com/syntheticpp/ninja/commits/ninja-for-cmake
The changes are only needed for msvc when the build
dir path contains
On 09.06.2012 16:22, Óscar Fuentes wrote:
After looking that the ouptput of ninja -v, the problem is that ninja is
recompiling some of the source files of llvm-tblgen.exe, which
regenerates the llvm-tblgen.exe executable, which in turn triggers the
regeneration of the files produced using that
Peter Kümmel syntheti...@gmx.net writes:
ninja -d explain shows the files which are dirty, and having a look at
the .d files shows that ninja couldn't parse them. (\\../)
I've switched to slashes in .d files and this fixes it.
All in stage/next, or
On 09.06.2012 01:29, Óscar Fuentes wrote:
Peter Kümmelsyntheti...@gmx.net writes:
It is not getting that far. It is not even running cmcldeps. :)
The command= line is bad, so nothing builds, and we get no .d files.
I added parentheses around cmcldeps, it should work now.
With your
On 09.06.2012 03:28, Bill Hoffman wrote:
fails in a new way:
http://open.cdash.org/viewConfigure.php?buildid=2345213
FAILED: CMAKE_CMCLDEPS_EXECUTABLE-NOTFOUND testCXXCompiler.cxx
CMakeFiles\cmTryCompileExec4166421573.dir\testCXXCompiler.cxx.obj.d
On 09.06.2012 09:10, Peter Kümmel wrote:
On 09.06.2012 01:29, Óscar Fuentes wrote:
Peter Kümmelsyntheti...@gmx.net writes:
It is not getting that far. It is not even running cmcldeps. :)
The command= line is bad, so nothing builds, and we get no .d files.
I added parentheses around
Hi Peter,
I agree, we need your/our changes at upstream!
I will switch to our github:
https://github.com/syntheticpp/ninja
On little more about ninja bootstrap:
Original bootstrap.py generated target rule:
ninja -t clean
does a really distclean. The re2c generted files are removed too!
To
On 09.06.2012 10:02, Claus Klein wrote:
Hi Peter,
I agree, we need your/our changes at upstream!
I will switch to our github:
https://github.com/syntheticpp/ninja
In times of git there is no our repository any more.
You could simply fork martine/ninja and push you changes
into your fork.
On 09.06.2012, at 10:25, Peter Kümmel wrote:
On 09.06.2012 10:02, Claus Klein wrote:
Hi Peter,
I agree, we need your/our changes at upstream!
I will switch to our github:
https://github.com/syntheticpp/ninja
In times of git there is no our repository any more.
Yes, I know, I meant
Peter Kümmel syntheti...@gmx.net writes:
Does clang has another build system which supports ninja?
Then we could compare the generated files.
No, AFAIK. What does work is all other build tools supported by cmake
(VS project files, nmake/jom). The command looks good. It is a custom
command that
The only thing to do is to figure out the prefix of /showIncludes, it's
hard coded atm:
https://github.com/syntheticpp/ninja/blob/cldeps/misc/cldeps.cc#L150
and to pass it to cldeps.
Interesting problem... Maybe just look for the second : or something
like that.
I compile a test file and
On 08.06.2012 18:10, Peter Kümmel wrote:
The only thing to do is to figure out the prefix of /showIncludes, it's
hard coded atm:
https://github.com/syntheticpp/ninja/blob/cldeps/misc/cldeps.cc#L150
and to pass it to cldeps.
Interesting problem... Maybe just look for the second : or
On 6/8/2012 12:38 PM, Peter Kümmel wrote:
I've pushed it to next to see if the BuildDepends test also passes on
the build server.
If someone giv it a try, I've uploaded binaries here
https://sourceforge.net/projects/cmakescript/files/
You need cmake and ninja (ninja/master, copy it into
On 08.06.2012 19:40, Bill Hoffman wrote:
On 6/8/2012 12:38 PM, Peter Kümmel wrote:
I've pushed it to next to see if the BuildDepends test also passes on
the build server.
If someone giv it a try, I've uploaded binaries here
https://sourceforge.net/projects/cmakescript/files/
You need
Hi Peter,can you please explain what is the state of your ninja fork.Is is sync with origin ninja?Will it merged later?Can you please apply my time-stamp patch?P.S.I tried to compile it with your CMakeLists.txt file, but it needs love on linux (UNIX) build hosts. //RegardsClaus
On 08.06.2012 21:11, Claus Klein wrote:
Hi Peter,
can you please explain what is the state of your ninja fork.
It only adds cldeps and the CMakeLists.txt, nothing else.
Is is sync with origin ninja?
Yes, I branched yesterday.
Will it merged later?
Can you please apply my time-stamp
It is not getting that far. It is not even running cmcldeps. :)
The command= line is bad, so nothing builds, and we get no .d files.
I added parentheses around cmcldeps, it should work now.
I also found that CMAKE_CL_SHOWINCLUDE_PREFIX is not set for different
CMakeLists.txt. I assume
Peter Kümmel syntheti...@gmx.net writes:
It is not getting that far. It is not even running cmcldeps. :)
The command= line is bad, so nothing builds, and we get no .d files.
I added parentheses around cmcldeps, it should work now.
With your binaries from 2 hours ago, changes on header
On 6/8/2012 5:15 PM, Peter Kümmel wrote:
It is not getting that far. It is not even running cmcldeps. :)
The command= line is bad, so nothing builds, and we get no .d files.
I added parentheses around cmcldeps, it should work now.
I also found that CMAKE_CL_SHOWINCLUDE_PREFIX is not set
On 6/6/2012 12:08 PM, Peter Kümmel wrote:
On 06.06.2012 16:27, Bill Hoffman wrote:
I will change the dashboard to use ninja
master. Right now it is still using your branch on git and is failing a
bunch of tests.
Now cmake prepends cmd.exe /c and the branched ninja also, so we have
cmd.exe /c
On 07.06.2012 16:21, Bill Hoffman wrote:
On 6/7/2012 10:08 AM, Peter Kuemmel wrote:
I changed the windows dashboard on dash2win64 to use ninja master.
Looks better now.
Thanks, only 2 left.
Do you have an idea why CTestTestTimeout doesn't work?
Not sure, might be a random thing. Let's
On 6/7/2012 10:43 AM, Peter Kümmel wrote:
Yes, I also think a solution on the cmake side make things much easier.
What about using cmake's build-in dependency parser. AFAIK there is one.
Could it be called by the command line?
I think it might be quicker to grab the cldep wrapper and try
Guessing configuration NoConfig
Start 82: BuildDepends
1/1 Test #82: BuildDepends . Passed5.06 sec
;)
Bill, this was a great idea with cldeps!
Only small patches for cldeps and cmake and we now have dependency tracking for
msvc.
A cldeps binary is here:
On 6/7/2012 5:46 PM, Peter Kümmel wrote:
Guessing configuration NoConfig
Start 82: BuildDepends
1/1 Test #82: BuildDepends . Passed 5.06 sec
;)
Bill, this was a great idea with cldeps!
Only small patches for cldeps and cmake and we now have dependency
tracking for msvc.
On 6/6/2012 7:14 AM, Peter Kümmel wrote:
Here the actual status of the Ninja generator.
The generator now uses Ninja's build-in response support.
- MSVC10
Dependency checking is still missing as essential feature,
but the rest is quite good:
The following tests FAILED:
82 - BuildDepends
On 06.06.2012 16:27, Bill Hoffman wrote:
Maybe there is a better solution, which would automatically fix a lot of
unit tests.
Can you bring that up on the ninja mailing list?
I tried it with not using slashes:
On 06.06.2012 16:27, Bill Hoffman wrote:
I will change the dashboard to use ninja
master. Right now it is still using your branch on git and is failing a
bunch of tests.
Now cmake prepends cmd.exe /c and the branched ninja also, so we have
cmd.exe /c cmd.exe /c cd which makes no sense.
Hi Peter,
Today I have tried to work with ninja on MSYS.
I have a view questions:
1. Is cmake build on MSYS or build on windows when you test with it
the ninja generator?
I tried the windows version, but it fails,
2. MSYS has a bash sh program, why is cmd /c used at a unix
On 06.06.2012 20:21, Claus Klein wrote:
Hi Peter,
Today I have tried to work with ninja on MSYS.
I have a view questions:
1. Is cmake build on MSYS or build on windows when you test with it the ninja
generator?
I tried the windows version, but it fails,
Hi Claus,
I only build with
Yes, without any problem.
But it was the MSYS Makefile generator if I remember right.
And as I said, cmake generates the dependency file and response files
itself while generation I think!
The are extra cmake files for that at CMakeFiles tree.
(gcc was not used, it seems a regex solution by
69 matches
Mail list logo
