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 reason
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 ensure
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 add_custom_
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 is
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 which
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 n
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 po
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 libra
10 matches
Mail list logo
