t a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index bbf8be0..0bde5ff 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
# CMake version number components.
set(CMake_VERSION_MAJOR 3)
set(CMake_VERSION_MINOR 15)
-set(CMake_VERSION_PATCH 20190729)
+set(CMake_VER
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/28/19 4:21 PM, Christoph Grüninger wrote:
> -include_directories(${CURSES_INCLUDE_PATH})
> +include_directories(${CURSES_INCLUDE_PATH}/ncurses/)
Why is that needed given the conditions here:
https://gitlab.kitware.com/cmake/cmake/blob/v3.15.1/Source/CursesDialog/form/form.h#L38-57
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
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via f6df9c2565ed00ec6f57c32a36dd451c60917f97 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via f22a2a1fa536127739baa8f6e020d9972adeb5c2 (commit)
via
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
15 matches
Mail list logo
