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
13 matches
Mail list logo
