On 2019-07-29 15:32-0400 Brad King wrote:
[...]We don't know what `main.cpp` includes
until after compiling it, by which point it is too late. It could have
`#include "anything.txt"` for example. CMake must add these pessimistic
dependencies to ensure a correct build.
Is this the real
On Mon, Jul 29, 2019 at 10:32 PM Brad King wrote:
>
> Even if we had that information we don't know what `main.cpp` includes
> until after compiling it, by which point it is too late. It could have
> `#include "anything.txt"` for example. CMake must add these pessimistic
> dependencies to
On 2019-07-29 13:24-0400 Brad King wrote:
On 7/29/19 11:50 AM, Dave Milter wrote:
Only source code are generated, so main.cpp -> main.cpp.o doesn't
depend on anything.
But generated by cmake build.ninja still require link of extern_lib
before starting main.cpp -> main.cpp.o
If there are any
On 7/29/19 3:22 PM, Dave Milter wrote:
>> Since then all objects in a target can start compiling independently
>> so long as that target does not depend on any targets with custom
>> commands.
See also https://gitlab.kitware.com/cmake/cmake/issues/17097
> Is any way to tell cmake that
On Mon, Jul 29, 2019 at 8:24 PM Brad King wrote:
>
> CMake 3.9 made this much better than it used to be:
>
> https://gitlab.kitware.com/cmake/cmake/merge_requests/430
>
> Since then all objects in a target can start compiling independently
> so long as that target does not depend on any targets
On 2019-07-29 18:50+0300 Dave Milter wrote:
On Mon, Jul 29, 2019 at 1:48 PM Bruce Stephens
wrote:
I think it's reasonable for CMake/Ninja to require the headers be
generated, especially since main.cpp does include one of them (though
CMake/Ninja doesn't know that until later). lib/lib1.cpp
On 7/29/19 11:50 AM, Dave Milter wrote:
> Only source code are generated, so main.cpp -> main.cpp.o doesn't
> depend on anything.
> But generated by cmake build.ninja still require link of extern_lib
> before starting main.cpp -> main.cpp.o
If there are any custom commands in any targets on
On Mon, Jul 29, 2019 at 1:48 PM Bruce Stephens
wrote:
>
> I think it's reasonable for CMake/Ninja to require the headers be
> generated, especially since main.cpp does include one of them (though
> CMake/Ninja doesn't know that until later). lib/lib1.cpp is more
> arguable, but I imagine there's
You might find it interesting to look at build.ninja. By the looks of
it there's a (phony) target guving the dependencies of the library.
(That's called cmake_object_order_depends_target_internal_lib) and
CMakeFiles/app.dir/main.cpp.o is depending on that.
Presumably the idea is that there's no
On 2019-07-28 23:39-0700 Alan W. Irwin wrote:
@Both: I also plan to look at whether this issue exists for
the internal library case so more later when I get that
corresponding simple test project implemented.
@Brad and David:
I have now implemented a simple test project for the internal
Hi to Dave and Brad:
@Dave: As you are probably already aware Brad is one of the primary
CMake developers so I think he should be in on this discussion.
@Brad:
Using Dave's simple test project
I confirmed the compilation delay issue below in detail for both the
-G"Ninja" case AND the -G"Unix
Hi,
On Mon, Jul 29, 2019 at 12:01 AM Alan W. Irwin
wrote:
>
> On 2019-07-28 19:03+0300 Dave Milter wrote:
>
> To help answer your question, I see no fundamental issues with your code
> above.
>
> If the latter is really true, that appears to me to be a CMake bug
> (although I cannot make the
On 2019-07-28 19:03+0300 Dave Milter wrote:
Hi,
I heard that ninja has great feature it allows build continue without
wainting full link.
So if you have library Lib and executable App,
source code of App may build in parallel with source code of Lib,
and sync only link stage. While other
Hi,
I heard that ninja has great feature it allows build continue without
wainting full link.
So if you have library Lib and executable App,
source code of App may build in parallel with source code of Lib,
and sync only link stage. While other build systems force build of Lib,
and only then
Hi
I am trying to use the Ninja generator to compile on a Windows machine using
the Visual Studio 11 compilers.
From a VS11 console I run cmake (version: 2.8.11.2 ):
cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_SYSTEM_NAME=MSVC ..
I then run Ninja (version 1.4.0)
ninja -v
and all
On 2014-02-12 17:22- Dominic Walsh wrote:
Hi
I am trying to use the Ninja generator to compile on a Windows machine using
the Visual Studio 11 compilers.
From a VS11 console I run cmake (version: 2.8.11.2 ):
cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_SYSTEM_NAME=MSVC ..
I then
Hi!
When using 'cmake .. -DCMAKE_TOOLCHAIN_FILE=../cmake/m3.cmake' with
the makefile generator this works prefectly but when using it with
'cmake -GNinja .. -DCMAKE_TOOLCHAIN_FILE=../cmake/m3.cmake' it fails
with the following message:
cmake -GNinja -DCMAKE_TOOLCHAIN_FILE=../cmake/m3.cmake
On 25.09.2012 23:17, Marcus D. Hanwell wrote:
I have tested it with VTK, and will likely look at some of the other
projects I am working on soon. So far so good - thanks for pushing
this forward. How much of this will make it into Qt Creator 2.6?
The essential patches are now in the official
The essential patches are now in the official 2.6 branch
great!
And I've back ported a CMake code completion patch to my 2.6-ninja branch.
It only doesn't work with Qt5.
But it works well with Qt4.
both in Windows and Linux.
It's maybe Qt5's bug. But I can't figure out what's the wrong.
There's also this patch
https://codereview.qt-project.org/#change,35006
which is on my 2.6-ninja branch, but it is not
a ninja relevant fix.
On 27.09.2012 04:23, Loaden wrote:
Two changes? I can found only one for ninja in here:
https://codereview.qt-project.org/#change,34851
B.T.W I am stay
On 25.09.2012 23:17, Marcus D. Hanwell wrote:
On Tue, Sep 25, 2012 at 2:56 PM, Peter Kümmel syntheti...@gmx.net wrote:
On 25.09.2012 17:29, Marcus D. Hanwell wrote:
On Thu, Sep 20, 2012 at 7:26 AM, Peter Kümmel syntheti...@gmx.net wrote:
On 19.09.2012 08:08, Wouter van Kleunen wrote:
Two changes? I can found only one for ninja in here:
https://codereview.qt-project.org/#change,34851
B.T.W I am stay 2.6 too. and Ninja Generator in 2.6 works well.
Thanks for your works.
2012/9/27 Peter Kümmel syntheti...@gmx.net
AFAIK 2.6 will come without any ninja support. At least two of
Also, the design goal of ninja was to build things as fast as
possible. And when convenience and speed are in conflict, prefer speed.
Although I can't totally disagree with Loadens comment to keep it simple
and your comment that the speed is reasonable now.
Op 24-9-2012 18:06, Wouter van
On Thu, Sep 20, 2012 at 7:26 AM, Peter Kümmel syntheti...@gmx.net wrote:
On 19.09.2012 08:08, Wouter van Kleunen wrote:
Peter,
i had 2.8.9-pre3 before, i upgraded to 2.8.9. But only after deleting
the CMakeLists user file from qtcreator, deleting the build directory
and restarting qtcreator
On 25.09.2012 17:29, Marcus D. Hanwell wrote:
On Thu, Sep 20, 2012 at 7:26 AM, Peter Kümmel syntheti...@gmx.net wrote:
On 19.09.2012 08:08, Wouter van Kleunen wrote:
Peter,
i had 2.8.9-pre3 before, i upgraded to 2.8.9. But only after deleting
the CMakeLists user file from qtcreator, deleting
On Tue, Sep 25, 2012 at 2:56 PM, Peter Kümmel syntheti...@gmx.net wrote:
On 25.09.2012 17:29, Marcus D. Hanwell wrote:
On Thu, Sep 20, 2012 at 7:26 AM, Peter Kümmel syntheti...@gmx.net wrote:
On 19.09.2012 08:08, Wouter van Kleunen wrote:
Peter,
i had 2.8.9-pre3 before, i upgraded to
On 23.09.2012 15:04, Wouter van Kleunen wrote:
I had the following idea to speed up the building even more, if a tool
can be build in ninja to list all files that need to be stat when
building a project. These files can be monitored by qtcreator and later
be provided as input again to ninja.
I prefer keep it simply.
2012/9/24 Peter Kümmel syntheti...@gmx.net
On 23.09.2012 15:04, Wouter van Kleunen wrote:
I had the following idea to speed up the building even more, if a tool
can be build in ninja to list all files that need to be stat when
building a project. These files can
When I tried with one of my larger projects the first no-op build after
a full build took something between 20 and 30 seconds but no-op builds
after that were below a second.
I'm not really sure what would cause this (I guess disk or filesystem
caching?).
Nils
On 09/24/2012 10:42 AM, Peter
On 24.09.2012 11:04, Nils Gladitz wrote:
When I tried with one of my larger projects the first no-op build after
a full build took something between 20 and 30 seconds but no-op builds
after that were below a second.
I'm not really sure what would cause this (I guess disk or filesystem
No, ninja is not really slow. Only when the filesystem caches are cold,
a no-op build does take a considerable time. So yeah, the performance
difference will not be very big when the caches are hot.
Wouter
Op 24-9-2012 11:17, Peter Kümmel schreef:
On 24.09.2012 11:04, Nils Gladitz wrote:
I had the following idea to speed up the building even more, if a tool
can be build in ninja to list all files that need to be stat when
building a project. These files can be monitored by qtcreator and later
be provided as input again to ninja. So my idea works as follows:
1. Build
Works well under Ubuntu 12.04 + Ninja 1.0.
Thanks a lot!
2012/9/20 Peter Kümmel syntheti...@gmx.net
On 19.09.2012 08:08, Wouter van Kleunen wrote:
Peter,
i had 2.8.9-pre3 before, i upgraded to 2.8.9. But only after deleting
the CMakeLists user file from qtcreator, deleting the build
On 19.09.2012 08:08, Wouter van Kleunen wrote:
Peter,
i had 2.8.9-pre3 before, i upgraded to 2.8.9. But only after deleting
the CMakeLists user file from qtcreator, deleting the build directory
and restarting qtcreator I was able to get the option to build with Ninja.
Anyway, it seems to work
Peter,
I guess removing just the build directory also seems to work.
I agree with your objections of the location the user file, the source
directory should stay clean. An inattentive moment and you have the file
in your version control.
Anyway, it seems to build now using an older version of
On 19.09.2012 09:48, Wouter van Kleunen wrote:
Peter,
I guess removing just the build directory also seems to work.
I agree with your objections of the location the user file, the source
directory should stay clean. An inattentive moment and you have the file
in your version control.
Anyway,
Peter,
yes I figured it would be something like that, compilations per seconds.
But did the ninja developers remove this option ?
I tried the ninja version you uploaded to github and this also works fine.
Wouter
On 19.09.2012 09:48, Wouter van Kleunen wrote:
Peter,
I guess removing just
On 19.09.2012 10:19, Wouter van Kleunen wrote:
Peter,
yes I figured it would be something like that, compilations per seconds.
But did the ninja developers remove this option ?
No, I've added it ;), but the official ninja binary is not a 1.0 version,
it's two months old.
I tried the ninja
Qt Creator 2.6 is beta now.
On github I've uploaded a patched version with Ninja support for CMake based
projects:
https://github.com/syntheticpp/qt-creator/downloads
When CDB is installed
I use the following rule to generate a precompiled header:
# Macro for creating precompiled headers
macro(add_precompiled_header HEADERFILE TRIGGERFILE SOURCESVAR)
set_source_files_properties(${${SOURCESVAR}}
PROPERTIES
COMPILE_FLAGS /Yu${HEADERFILE}
On Tue, Apr 17, 2012 at 6:43 PM, Clifford Yapp cliffy...@gmail.com wrote:
On Tue, Apr 17, 2012 at 4:59 PM, David Cole david.c...@kitware.com
wrote:
Hello CMake Ninja fans,
We are going to be creating the CMake 2.8.8 final release tomorrow.
However,
there are issues reported for the
Hello CMake Ninja fans,
We are going to be creating the CMake 2.8.8 final release tomorrow.
However, there are issues reported for the ninja generator. Does anybody
consider them showstoppers ?? (I do not, but want a sanity check from the
community -- we will get bug fixes into master and
On Tue, Apr 17, 2012 at 4:59 PM, David Cole david.c...@kitware.com wrote:
Hello CMake Ninja fans,
We are going to be creating the CMake 2.8.8 final release tomorrow. However,
there are issues reported for the ninja generator. Does anybody consider
them showstoppers ??
David,
Does the latest
13069 looks reasonably serious, but I won't consider it a show-stopper.
It's relatively easy to work around.
--
Best regards,
Alexander.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic
Collingbourne; Clifford Yapp
Cc: CMake List
Subject: Re: [CMake] CMake + Ninja
I was wondering if there was any plans to add the feature mentioned below?
That said, a way of saying build every target in this subdirectory
(for example, by specifying that subdirectory as a target
Nico,
Thank you for your response.
-Kris
-Original Message-
From: Nicolas Desprès [mailto:nicolas.desp...@gmail.com]
Sent: Wednesday, April 11, 2012 2:49 PM
To: Malfettone, Kris
Cc: Peter Collingbourne; Clifford Yapp; CMake List
Subject: Re: [CMake] CMake + Ninja
It is in my
; Clifford Yapp
Cc: CMake List
Subject: Re: [CMake] CMake + Ninja
I was wondering if there was any plans to add the feature mentioned below?
That said, a way of saying build every target in this subdirectory
(for example, by specifying that subdirectory as a target on the
command
Clifford Yapp cliffy...@gmail.com
writes:
On Sat, Jan 14, 2012 at 3:25 PM, Peter Collingbourne pe...@pcc.me.uk wrote:
I managed to test these changes on a Mac and it fixed all but 7
test failures, so I rolled it into the ninja-generator-pr branch.
In terms of applications I didn't have time
On Sun, Jan 22, 2012 at 2:50 PM, Óscar Fuentes o...@wanadoo.es wrote:
Clifford Yapp cliffy...@gmail.com
writes:
On Sat, Jan 14, 2012 at 3:25 PM, Peter Collingbourne pe...@pcc.me.uk wrote:
I managed to test these changes on a Mac and it fixed all but 7
test failures, so I rolled it into the
Confirmed - working now on Mac building BRL-CAD - thanks!
Cliff
On Sat, Jan 14, 2012 at 3:25 PM, Peter Collingbourne pe...@pcc.me.uk wrote:
I managed to test these changes on a Mac and it fixed all but 7
test failures, so I rolled it into the ninja-generator-pr branch.
In terms of
On Tue, Jan 10, 2012 at 04:54:07PM -0500, Clifford Yapp wrote:
On Tue, Jan 10, 2012 at 12:03 AM, Peter Collingbourne pe...@pcc.me.uk wrote:
The attached patch should add support for TARGET_INSTALLNAME_DIR.
Please let me know if it works -- it's untested, as I don't have easy
access to a
On Tue, Jan 10, 2012 at 12:03 AM, Peter Collingbourne pe...@pcc.me.uk wrote:
The attached patch should add support for TARGET_INSTALLNAME_DIR.
Please let me know if it works -- it's untested, as I don't have easy
access to a Mac.
Awesome - thank you! It'll be a week or so before I have
On Fri, Jan 06, 2012 at 02:08:24PM -0500, Clifford Yapp wrote:
Peter,
FYI, I'm seeing a problem with the BRL-CAD build on the Mac with CMake
+ ninja using the latest git versions - when I try to run tclsh, I get
a problem with it trying to link
TARGET_INSTALLNAME_DIRlibtcl.8.5.dylib instead
Hi,
I didn't time it, but I was able to use ninja with kdelibs and grantlee (my
smaller Qt project).
Clifford Yapp wrote:
In case anybody else wants to give ninja a spin, here's what I did to
test it (using bash as a shell):
git clone git://github.com/martine/ninja.git
git clone -b
Peter Collingbourne's ongoing work with CMake support for ninja (and
vice versa) was recently announced as being able to build multiple
large projects:
http://public.kitware.com/pipermail/cmake-developers/2011-November/002490.html
BRL-CAD was on the list, and in trials last night I confirmed
Peter,
FYI, I'm seeing a problem with the BRL-CAD build on the Mac with CMake
+ ninja using the latest git versions - when I try to run tclsh, I get
a problem with it trying to link
TARGET_INSTALLNAME_DIRlibtcl.8.5.dylib instead of the local
libtcl.8.5.dylib in the build directory. This doesn't
56 matches
Mail list logo
