Here is a very first shot of ninja on Windows:
https://github.com/syntheticpp/ninja/tree/qprocess
Sorry, it links against Qt, but the original code depends
on fork() and Qt was the fastest way to get ninja running
on Windows.
Maybe there are big show-stopper bugs, but
On 03.10.2011 15:03, Brad King wrote:
On 10/2/2011 1:41 PM, Peter Collingbourne wrote:
I have modified the commit message to include more details, and pushed
a modified branch to github.
I've fetched the latest version of the branch. Thanks for the updates.
-Brad
Could you also enable
On 04.10.2011 23:19, Peter Kümmel wrote:
On 03.10.2011 15:03, Brad King wrote:
On 10/2/2011 1:41 PM, Peter Collingbourne wrote:
I have modified the commit message to include more details, and pushed
a modified branch to github.
I've fetched the latest version of the branch. Thanks
Maybe this is a bit late, but wouldn't it be much
simpler to get this feature with a namespace
inspired approach:
http://public.kitware.com/Bug/view.php?id=11793
All within a namespace has the same scope as an
add_subdirectory added target. This way we get more
than the
On 09.12.2011 22:23, Brad King wrote:
On 12/9/2011 3:44 PM, Peter Kümmel wrote:
Maybe this is a bit late, but wouldn't it be much
simpler to get this feature with a namespace
inspired approach:
http://public.kitware.com/Bug/view.php?id=11793
I think the namespace approach will be more
I played a bit with the Ninja generator on Windows,
and added some hacks to make it a bit running:
https://github.com/syntheticpp/CMake/commit/0a55b61271106eb7c3319340f2c54f6bab3c0f8b
Here are the problems I found so far:
- Paths like 'c:\' - Ninja now supports colon escaping c: - c$:
Is
On 31.01.2012 04:55, Bill Hoffman wrote:
- Paths like 'c:\' - Ninja now supports colon escaping c: - c$:
Is there a single place where the escaping could be done?
Can we use Posix paths in the windows ninja generator instead of windows
paths? I am guessing ninja would be happier with them.
On 31.01.2012 16:19, Peter Collingbourne wrote:
On Tue, Jan 31, 2012 at 12:15:59AM +0100, Peter Kümmel wrote:
I played a bit with the Ninja generator on Windows,
and added some hacks to make it a bit running:
https://github.com/syntheticpp/CMake/commit/0a55b61271106eb7c3319340f2c54f6bab3c0f8b
Therefore the question, if there is a single place where
all the slashes could be replaced by backslashes before we write
them down to the ninja file.
All of that is done in the cmLocalGenerator for the NMake and Jom
generators that use windows paths:
enum RelativeRoot { NONE, FULL,
On 01.02.2012 20:56, Peter Collingbourne wrote:
On Tue, Jan 31, 2012 at 10:42:40PM -0500, Bill Hoffman wrote:
On 1/31/2012 5:58 PM, Peter Collingbourne wrote:
That will
be handy when it comes time to integrate this work upstream because
KWSys is shared with other projects.
Why isn't
On 01.02.2012 21:04, Peter Collingbourne wrote:
On Tue, Jan 31, 2012 at 10:58:32PM +, Peter Collingbourne wrote:
On Tue, Jan 31, 2012 at 05:06:28PM -0500, Brad King wrote:
On 1/31/2012 4:44 PM, Peter Kümmel wrote:
OK, thanks. I already noticed the usage of OutputFormat::SHELL.
Then I have
On 31.01.2012 23:40, Peter Collingbourne wrote:
On Tue, Jan 31, 2012 at 10:32:23PM +0100, Peter Kümmel wrote:
On 31.01.2012 16:19, Peter Collingbourne wrote:
On Tue, Jan 31, 2012 at 12:15:59AM +0100, Peter Kümmel wrote:
- Paths like 'c:\' - Ninja now supports colon escaping c: - c
On 04.02.2012 11:48, Bill Hoffman wrote:
Why does the ninja generator need to use? I am pretty sure the other
CMake generators do not need to use.
Most of them come from the working directory: cd foo g++
They could be worked around easly by adding a new variable to the rules.
Seems
On 15.02.2012 18:17, Bill Hoffman wrote:
On 2/15/2012 11:20 AM, Nicolas Desprès wrote:
For compiling and testing you can find all the information in the
HACKING file.
Well, this is ugly:
--HACKING
Windows development on Windows:
- install mingw, msys, and python
- in the mingw
Hi Bill,
here is up-to-date cmake file:
https://github.com/syntheticpp/dartruntime/tree/cmake
Sorry, CP error, I mean:
https://github.com/syntheticpp/ninja/tree/cmake
It works on Win, Linux, Mac and ll gtest based unit test passes.
The cmake file is in misc/.
I also asked for
On 15.02.2012 19:31, Bill Hoffman wrote:
OK, so ninja does not seem to work on windows for me...
I got ninja from here:
git://github.com/martine/ninja.git
branch master
I got cmake from here:
remotes/stage/ninja-generator
I removed the if(UNIX) in the cmake tree and built cmake with
On 16.02.2012 04:51, Bill Hoffman wrote:
On 2/15/2012 5:52 PM, Peter Kümmel wrote:
In summary:
- use the CMakeLists.txt from
https://github.com/syntheticpp/ninja/tree/cmake
- on Windows use ninja from
https://github.com/syntheticpp/ninja/tree/token-splitter
and wait and see
On 16.02.2012 21:38, Bill Hoffman wrote:
On 2/16/2012 2:57 PM, Peter Kümmel wrote:
They are not interested.
There is another patch in the pipeline but with
this the current generator doesn't work.
Use the official ninja and drop Win atm.
Bummer. I am most interested in windows. Would love
I did find out that the ninja generator is not part of the cmake
bootstrap.
Where is the actual cmake repository and branch which contains the ninja
generator
on which we should work?
Peter
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
On 19.02.2012 07:21, Peter Collingbourne wrote:
This caused custom commands to be double encoded, causing a test failure
on *nix. I reverted part of your changes to fix the test failures and
also had a look at implementing the escaping rules correctly. With the
changes I made, I was able to
On 09.03.2012 10:40, Nicolas Desprès wrote:
On Fri, Mar 9, 2012 at 3:24 AM, Peter Collingbournepe...@pcc.me.uk wrote:
On Tue, Mar 06, 2012 at 03:56:24PM -0500, Bill Hoffman wrote:
On 3/6/2012 1:29 PM, Peter Collingbourne wrote:
We can certainly do that, but the ninja binary would need to be
On 09.03.2012 03:34, Peter Collingbourne wrote:
On Thu, Mar 08, 2012 at 05:44:09PM -0500, Bill Hoffman wrote:
Thoughts?
Hi Bill,
I thought about this for a while and I decided that this probably
isn't a good idea for a few reasons:
1) It is inaccurate. The Ninja generator uses a
On 10.03.2012 21:10, David Cole wrote:
If somebody else has done work since the last time you pushed it to
'stage', then you should rebase any of your work on top of that to
keep a linear topic branch history.
git checkout ninja-generator # (your local one...)
git pull --rebase stage
Explanations of failing tests:
- The Plugin test is failing on Windows because the ENABLE_EXPORTS
target flag is not being processed:
Attached a patch which fixes this test. It was not an unprocessed flag
but a not existing directory.
I don't know where to commit this patch.
On 07.04.2012 20:46, David Cole wrote:
On Fri, Apr 6, 2012 at 3:49 PM, David Coledavid.c...@kitware.com wrote:
On Fri, Apr 6, 2012 at 3:10 PM, Peter Kümmelsyntheti...@gmx.net wrote:
One nitpick with the patch, the KWStyle test fails because lines 58
63 exceed our max line length limit (79
On 07.04.2012 21:56, Peter Kümmel wrote:
By default Ninja support is not enabled on Windows and Mac, somehow it was build
the last times but I touched the cmake code there and introduced a FORCE:
http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=f93e81858b5e1243714ed7f26aadfc791a7b0ff0
On 08.04.2012 01:53, Bill Hoffman wrote:
On 4/7/2012 5:03 PM, Peter Collingbourne wrote:
On Sat, Apr 07, 2012 at 10:00:41PM +0200, Peter Kümmel wrote:
On 07.04.2012 21:56, Peter Kümmel wrote:
By default Ninja support is not enabled on Windows and Mac, somehow it was build
the last times
On 08.04.2012 14:12, Óscar Fuentes wrote:
Peter Kümmelsyntheti...@gmx.net writes:
I know ninja should not be enabled on other platforms than Linux, and it wasn't,
even with my patch. This was not a try the enable ninja through the backdoor!
I've fixed it and changed the message so it could
On 19.04.2012 16:21, Bill Hoffman wrote:
On 4/19/2012 4:16 AM, Nicolas Desprès wrote:
That's possible indeed. There are discussions whether to support all
compilers deps file formats inside Ninja or in another program (see
the deplist branch and discussion thread). The deplist branch is an
On 21.04.2012 13:24, David Cole wrote:
On Sat, Apr 21, 2012 at 6:53 AM, Peter Kümmel syntheti...@gmx.net
mailto:syntheti...@gmx.net wrote:
On 19.04.2012 16:21, Bill Hoffman wrote:
On 4/19/2012 4:16 AM, Nicolas Desprès wrote:
That's possible indeed
On 04.06.2012 17:59, Bill Hoffman wrote:
We are you using the linker support for response files? I thought ninja
was handling this with its own response files?
rspfile, rspfile_content
rule link
command = link.exe /OUT$out [usual link flags here] @$out.rsp
rspfile = $out.rsp
On 04.06.2012 23:13, Bill Hoffman wrote:
On 6/4/2012 2:22 PM, Peter Kümmel wrote:
We use ninja's response files:
# Rule for linking CXX static library.
rule CXX_STATIC_LIBRARY_LINKER
command = E:\sandbox\MinGW32\bin\ar.exe cr $out $LINK_FLAGS @$out.rsp
description = Linking CXX static
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.
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
On 06.06.2012 21:32, Brad King wrote:
On Tue, Jun 5, 2012 at 6:15 PM, Peter Kümmelsyntheti...@gmx.net wrote:
The commits are here
http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/ninja-rspfile
FYI, std::ostringstream is not portable to ancient platforms:
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 07.06.2012 20:44, Claus Klein wrote:
Hi Peter,
It seem not so important, but is it wanted that ninja generator creates
relative targets to PROJECT_BINARY_DIR?
claus-kleins-macbook-pro:Example clausklein$ ninja -t query Hello/libHello.a
Hello/libHello.a:
input: CXX_STATIC_LIBRARY_LINKER
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:
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
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
patch?
More interesting would be to bring it upstream.
P.S.
I tried to compile it with your CMakeLists.txt file, but it needs love on linux
(UNIX) build hosts.
Oh, yes, thanks. The last day I'm only on windows.
//Regards
Claus
On 07.06.2012, at 23:46, Peter Kümmel wrote:
Guessing
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
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
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 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
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.
193: Processing /Users/davidcole/Dashboards/My
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 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
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
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
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\
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 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 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
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:
https://github.com/syntheticpp/ninja
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 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 string
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
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
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
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
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
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 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
On 14.06.2012 17:05, Bill Hoffman wrote:
Now that the ninja generator is on by default on windows, it is not
building on the old compilers. Looks like it is missing a std:: on a
make_pair call.
I'll have a look at it. (I'm also busy fixing the broken Linux tests since my
last commit)
On 14.06.2012 19:43, David Cole wrote:
I've got a fix locally in the ninja normal target generator:
std::string flags = (targetType == cmTarget::EXECUTABLE
? vars[FLAGS]
: vars[ARCH_FLAGS]);
I found a new problem were I could not
find a good solution:
cmd.exe /c $PRE_LINK
cmake.exe -E vs_link_dll $in
$POST_LINK
Assume $in is to big for the command line,
what could be done then. First I thought
$PRE_LINK and $POST_LINK are then empty
and could be dropped, but this is wrong.
Is
On 15.06.2012 00:33, Peter Kümmel wrote:
I found a new problem were I could not
find a good solution:
cmd.exe /c $PRE_LINK
cmake.exe -E vs_link_dll $in
$POST_LINK
Assume $in is to big for the command line,
what could be done then. First I thought
$PRE_LINK and $POST_LINK are then empty
On 26.06.2012 23:00, Bill Hoffman wrote:
On 6/26/2012 2:42 PM, Claus Klein wrote:
yes, sure,
On Darwin, I simply do:
cmake -G 'Eclipse CDT4 - Ninja'
-DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=1 ../LMX
That works with any cmake project I work.
Nightly build on
uname -a
Darwin
On 04.07.2012 02:10, J Decker wrote:
ninja looks promising as an inbetween; lcc of course has it's own
make. I however don't find ninja on windows latest download...
there's a couple references in the /share/
Unofficial binaries you could find here:
On 06.07.2012 12:54, Nicolas Desprès wrote:
Hi,
I finally found the time to fix the Ninja generator on OS X. Mainly I
have fixed ExportImport and Qt4Deploy. I based my work on jkp's work
(https://github.com/jkp/CMake/commits/jkp/ninja-generator). Although
there are other patches in this branch,
On 09.07.2012 17:35, David Cole wrote:
Not sure what your main goal was for that test, but a similar test already
exists to ensure proper definition of
http://www.cmake.org/Bug/view.php?id=13069
Seems there is no test which checks if -DCMAKE_BUILD_TYPE=XXX triggers the
selection of the
On 07.07.2012 20:54, Nicolas Desprès wrote:
I have pushed the re-factor patch. Let me know what do you think. I
have tested on Linux and MacOSX with the Makefile and Ninja generator
and both work fine.
I've tested it here and BundleTest still fails.
It doesn't install the Resource files.
On 17.07.2012 15:39, Nicolas Desprès wrote:
On Tue, Jul 17, 2012 at 3:29 PM, Bill Hoffmanbill.hoff...@kitware.com wrote:
On 7/17/2012 8:10 AM, Peter Kümmel wrote:
On 17.07.2012 13:45, David Cole wrote:
Peter, can you rebase this on current 'master', push this to our stage
as a branch
On 17.07.2012 19:11, Nicolas Desprès wrote:
I don't like the friend keyword either but I try to follow the current
architecture of CMake.
Yes, I know.
In cmLocalUnixMakefileGenerator you can see that:
friend class cmMakefileTargetGenerator;
friend class
On 17.07.2012 19:32, Bill Hoffman wrote:
On 7/17/2012 1:21 PM, Peter Kümmel wrote:
OK, maybe it is simpler to add a the functions to cmNinjaTargetGenerator which
forwards the call to the Local/Global classes.
Lets just add the friend stuff for now so we can get the dashboard
building again
On 18.07.2012 11:58, Nicolas Desprès wrote:
On Tue, Jul 17, 2012 at 11:39 PM, Bill Hoffmanbill.hoff...@kitware.com wrote:
On 7/17/2012 1:43 PM, Peter Kümmel wrote:
On 17.07.2012 19:32, Bill Hoffman wrote:
On 7/17/2012 1:21 PM, Peter Kümmel wrote:
OK, maybe it is simpler to add
On 18.07.2012 11:58, Nicolas Desprès wrote:
On Tue, Jul 17, 2012 at 11:39 PM, Bill Hoffmanbill.hoff...@kitware.com wrote:
On 7/17/2012 1:43 PM, Peter Kümmel wrote:
On 17.07.2012 19:32, Bill Hoffman wrote:
On 7/17/2012 1:21 PM, Peter Kümmel wrote:
OK, maybe it is simpler to add
On 21.07.2012 11:22, Claus Klein wrote:
I can not understand the output, for me this test does not work.
Change Dir:
/Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/BuildDepends/Project Run
Build
Command:/usr/local/bin/ninja [1/14] Building CXX object
CMakeFiles/foo.dir/foo.cxx.o [2/14]
On 21.07.2012 12:08, Peter Kümmel wrote:
Can anyone please help?
You could not run the BuildDepends test twice.
You always have to remove the BuildDepends folder in
the build tree before running it again.
Seems like a bug in the cmake file for the test.
Or a bug in the ninja generator
On 21.07.2012 19:55, Nicolas Desprès wrote:
Thanks for the feedback. Here the patches to cherry-pick:
https://github.com/polrop/CMake/commit/af6b1979071e463ae397d3512e3a0366b58919f8
https://github.com/polrop/CMake/commit/be8039fab069b0efb2469932617b3ca8826d1865
Thanks, pushed them to stage.
I've added a nice feature to ninja which is now upstream:
By setting the environment variable NINJA_STATUS
bash:
export NINJA_STATUS=[%s/%t %o(%c)/s]
cmd.exe (with space at the end):
set NINJA_STATUS=[%s/%t %o(%c)/s]
Ninja prints the overall processed files per second and
On 28.07.2012 11:43, Shlomi Fish wrote:
Nice.
I was now able to get the Freecell Solver test suite to pass with ninja test,
but there is one problem: when I run ninja -vv test, then ninja displays the
line
[1/1] cd /home/shlomif/progs/freecell/git/fc-solve/fc-solve/source/n
perl
I wanna add a way to put all .pdb files into one directory.
Therefore I've introduced the variable CMAKE_DEBUG_SYMBOL_DIRECTORY
which could be set to an existing directory.
I patched all the places where GetPDBName() is used.
Is it OK to merge this patch to next?
On 22.08.2012 14:47, Brad King wrote:
On 08/22/2012 08:41 AM, Peter Kümmel wrote:
I wanna add a way to put all .pdb files into one directory.
Therefore I've introduced the variable CMAKE_DEBUG_SYMBOL_DIRECTORY
which could be set to an existing directory.
I patched all the places where
Here an example how a Lua based build system could look like:
https://github.com/deplinenoise/tundra/blob/master/tundra.lua
And more details here:
http://deplinenoise.files.wordpress.com/2011/04/tundra43.pdf
Peter
--
Powered by www.kitware.com
Visit other Kitware open-source projects
On 22.08.2012 15:13, Brad King wrote:
On 08/22/2012 09:09 AM, Peter Kümmel wrote:
I wouldn't introduce a variable which will become obsolete, because
of the backward compatibility matra such a variable could never be removed.
Why not simply document that SYMBOL_OUTPUT_DIRECTORY is currently
On 04.09.2012 21:56, Brad King wrote:
On 09/04/2012 02:16 PM, Peter Kümmel wrote:
On 04.09.2012 18:56, Bill Hoffman wrote:
The BuildDepends test has been failing for some time now:
http://open.cdash.org/viewUpdate.php?buildid=2522326
It seems to be from this commit:
http://cmake.org/gitweb
On 05.09.2012 13:31, Brad King wrote:
On 09/04/2012 07:46 PM, Peter Kümmel wrote:
Any optimization that skips dependency checks should
be done only for the first form, and never for the
second form. This distinction should cover the
BuildDepends test case too.
http://cmake.org/gitweb?p=stage
On 05.09.2012 20:54, Alexander Neundorf wrote:
Something like
$ codeblocks --build foo.cbp
Ah, a new build system ;)
This is more or less necessary so cmake can run its test suite to verify the
generator works correctly.
Alex
--
--
Powered by www.kitware.com
Visit other Kitware
On 08.09.2012 11:51, Benjamin Eikel wrote:
Am Freitag, 7. September 2012 um 18:59:49 schrieb Bill Hoffman:
On 9/7/2012 12:13 PM, Benjamin Eikel wrote:
Yes, I have seen that in the beginning when the generator did not work as
expected. At the moment, it builds from the command line, but only if
On 09.09.2012 19:50, Benjamin Eikel wrote:
Dear CMake developers,
I looked at the output of my CMake build/bin/cmake --system-information
with the Unix Makefiles generator and the new Code::Blocks generator. For the
new Code::Blocks generator, the variables CMAKE_LIBRARY_ARCHITECTURE (and the
On 25.09.2012 14:53, Mantis Bug Tracker wrote:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13559
==
There is the
1 - 100 of 123 matches
Mail list logo
