On 15.03.2015 16:42, Tobias Hunger wrote:
Hi Peter,
CMake does know all the headers or it could not decide which files
need rebuilding.
How would making cmake parse a file in the syntax of another build
system help creator understand existing cmake projects?
The idea was that qtcreator then
On 12.03.2015 16:24, Tobias Hunger wrote:
A list of *all* headers used during the building of the target would
be fine. There is no need to filter that list down in any way.
CMake has that information: Without it cmake could not possibly know
when a cpp file needs rebuilding. It would not be
On 06.06.2014 16:53, Sam Spilsbury wrote:
On Fri, Jun 6, 2014 at 10:49 PM, Brad King brad.k...@kitware.com wrote:
On 06/06/2014 10:12 AM, Sam Spilsbury wrote:
Ninja was passing a relative path to the compiler which causes
__FILE__ to use that same relative path. This was causing the test to
Is there a way to configure the default generator for command-line cmake calls?
If it's not configurable, what about reading a default from a environment
variable?
Peter
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
On 26.11.2013 09:17, Nils Gladitz wrote:
On 11/25/2013 06:31 PM, Nils Gladitz wrote:
On 25.11.2013 18:21, Peter Kümmel wrote:
Also this system is localized? I don't see any prefixes, e.g. here
http://open.cdash.org/testDetails.php?test=220476713build=3114166
The system indeed has a german
On 25.11.2013 10:34, Nils Gladitz wrote:
I found output like this:
Hinweis: Einlesen der Datei: c:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\INCLUDE\string
Hinweis: Einlesen der Datei:c:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\INCLUDE\istream
[...]
In local
On 25.11.2013 11:54, Nils Gladitz wrote:
On 11/25/2013 11:23 AM, Peter Kümmel wrote:
1.4.0 is too old, see here
http://public.kitware.com/pipermail/cmake-developers/2013-October/008687.html
I retried with master (7ccecee4f10036a74942ca406dcd4a7b41f291b4) but the
problem seems to persist
On 25.11.2013 14:08, Nils Gladitz wrote:
On 11/25/2013 12:53 PM, Nils Gladitz wrote:
I'll try running the cmake testsuite to see if it breaks dependency scanning as
well.
There were no test failures:
http://open.cdash.org/viewTest.php?onlypassedbuildid=3114166
So I assume it correctly
On 25.11.2013 17:56, Nils Gladitz wrote:
On 25.11.2013 17:53, Peter Kümmel wrote:
Does rules.ninja contain
msvc_deps_prefix = Hinweis: Einlesen der Datei:
AND the compile rules define deps = msvc?
I don't have access to the system right now but I think I saw both.
Nils
Also this system
OK, merged a new version to next.
Now the docu looks much better, thanks!
On 25.11.2013 15:13, Brad King wrote:
On 11/23/2013 09:04 AM, Peter Kümmel wrote:
OK, I've pushed a patch which adds
JOB_POOLS
JOB_POOL_LINK
JOB_POOL_COMPILE
CMAKE_JOB_POOL_LINK
CMAKE_JOB_POOL_COMPILE
Great! Here
The purpose of SetPropertyDefault is to lookup the variable for you.
You just need
this-SetPropertyDefault(JOB_POOL_COMPILE, 0);
this-SetPropertyDefault(JOB_POOL_LINK, 0);
The second argument is just what to use when the variable is not set.
Ah, very comfortable. I updated next.
Brad
On 11.11.2013 18:33, Matthew Woehlke wrote:
On 2013-11-11 12:17, Nils Gladitz wrote:
On 11.11.2013 17:38, Matthew Woehlke wrote:
What else can you do? Until you re-run CMake, there is no way to know
how many edges need to be executed. Even if ninja were to show the
maximum possible number of
On 12.11.2013 16:33, Brad King wrote:
On 11/09/2013 06:39 AM, Peter Kümmel wrote:
On 08.11.2013 17:22, Brad King wrote:
Without context the name POOL may not have clear meaning to
a reader not already familiar with Ninja's feature. I think
a name like JOB_POOL would be clearer.
Even JOB_POOL leaves
On 08.11.2013 17:22, Brad King wrote:
On 11/05/2013 02:15 PM, Peter Kümmel wrote:
I merged a proposal to next which adds support for Ninja's pool:
http://martine.github.io/ninja/manual.html#ref_pool
This will be a really nice feature to support.
Thanks for the detailed comments. Below
I merged a proposal to next which adds support for Ninja's pool:
http://martine.github.io/ninja/manual.html#ref_pool
It adds three new properties, POOLS, LINK_POOL, COMPILE_POOL:
http://www.cmake.org/cmake/help/git-next/manual/cmake-properties.7.html
With a pool it is possible to limit
On 21.10.2013 16:19, Bill Hoffman wrote:
On 10/19/2013 7:09 AM, Peter Kümmel wrote:
CMake now uses Ninja's database feature for dependency
tracking.
An empty build now takes about a third less (e.g. Clang
160ms-100ms)
Therefore ninja master is needed, please update your build
server
On 20.10.2013 17:13, David Cole wrote:
Therefore ninja master is needed, please update your build
server.
When a particular ninja 'master' is required, it would be
great if you could recommend a given snapshot by git commit
rather than just saying 'master'. Especially for those of us
On 05.09.2013 14:28, Daniele E. Domenichelli wrote:
I'd like to be able to modify files, commit, and push from the external
git repositories,
For this use case you could use submodules in git:
http://git-scm.com/book/en/Git-Tools-Submodules
Peter
--
Powered by www.kitware.com
Visit
On 02.04.2013 15:19, Brad King wrote:
Hi Peter,
We've come across a case where the Makefile, VS, and Xcode generators
work but Ninja does not::
cmake_minimum_required(VERSION 2.8.10)
project(DependSideEffect C)
add_library(A a.c)
add_custom_command(
TARGET A POST_BUILD
COMMAND
On 17.02.2013 08:36, Patrick Gansterer wrote:
Hi,
Am 09.02.2013 um 10:39 schrieb Peter Kümmel:
On 30.01.2013 15:17, Brad King wrote:
On 01/26/2013 12:33 PM, Patrick Gansterer wrote:
to compile WindowsCE C++ project with Ninja I need the attached patch
applied.
One problem with this patch
On 30.01.2013 15:17, Brad King wrote:
On 01/26/2013 12:33 PM, Patrick Gansterer wrote:
to compile WindowsCE C++ project with Ninja I need the attached patch
applied.
One problem with this patch is that it moves the initialization of C
and CXX languages until after the RC initialization which
Today I stumbled over Steven's Grantlee release blog
http://steveire.wordpress.com/2012/11/01/grantlee-0-3-0-codename-leistungswasser-now-available/
and read about TestCocoon.
Last year Alex had the idea to test it with CMake:
A unit tests for expressions is broken for ninja:
http://open.cdash.org/testDetails.php?test=161505814build=2596684
ninja prints the wrong parameter as it is used in the cmake file,
include_directories($TARGET_PROPERTY:Invali/dTarget,INCLUDE_DIRECTORIES)
but the test wants the $ escaped
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
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 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 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 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 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
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
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
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
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.
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 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 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 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 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 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 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 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 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
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 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
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 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.
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 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:
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 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 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 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 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 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
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.
1 - 100 of 123 matches
Mail list logo
