Ninja always triggers a re-build / header dependency problem

[harald....@me.com]

Hello, 

I am using ninja (via cmake) for a cross compiler. Currently I have the problem, that even if nothing has changed, a re-build is done for the complete project.

I suspect a problem with the dependency file format that is somehow created by the cross-compiler, but probably can not be properly interpreted by ninja.

The execution of ninja -t deps with the .ninja_deps file produces the following example output:

CMakeFiles/Core0.elf.dir/Module_A/File_A.c.obj: #deps 74, deps mtime 529581474 (VALID)

    C:/PROJECTS/repos/000_swprj/Sources/Module_A/File_A.c

    C:/PROJECTS/repos/000_swprj/Sources/Module_A/File_A.c

    File_A.o

    C:/PROJECTS/repos/000_swprj/Sources/Module_A/Header_A.h

    C:/PROJECTS/repos/000_swprj/Sources/Module_A/Header_A.h

    File_A.o

    C:/PROJECTS/repos/000_swprj/Sources/Module_A/Header_y.h

    C:/PROJECTS/repos/000_swprj/Sources/Module_A/Header_y.h

... etc ...

CMakeFiles/Core0.elf.dir/Module_A/File_B.c.obj: #deps 140, deps mtime 529581475 (VALID)

    C:/PROJECTS/repos/000_swprj/Sources/Module_A/File_B.c

    C:/PROJECTS/repos/000_swprj/Sources/Module_A/File_B.c

    File_B.o

    C:/PROJECTS/repos/000_swprj/Sources/Module_A/Header_B.h

   

        ... etc ...

As you can see, the object file extension differs and each dependency file is listed twice...

Has somebody an explanation, why ninja triggers always the complete build? Or at least can tell me, how the dependency output should look like?

BTW:  I called ninja with -d keepdepfile, but the original dep-file, created by the compiler is not there....

Thanks in advance!!!

Harald

[Evan Martin]

Try "ninja -d explain your_build_target" to see some debug info about why it's rebuilding.

--
You received this message because you are subscribed to the Google Groups "ninja-build" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ninja-build+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Harald Spiertz]

Thanks! 

The output is:

ninja explain: CMakeFiles/Core0-complete is dirty

ninja explain: Core0-prefix/src/Core0-stamp/Core0-done is dirty

ninja explain: Core0-prefix/src/Core0-stamp/Core0-install is dirty

ninja explain: Core0-prefix/src/Core0-stamp/Core0-mkdir is dirty

ninja explain: Core0-prefix/src/Core0-stamp/Core0-download is dirty

ninja explain: Core0-prefix/src/Core0-stamp/Core0-update is dirty

ninja explain: Core0-prefix/src/Core0-stamp/Core0-patch is dirty

ninja explain: Core0-prefix/src/Core0-stamp/Core0-configure is dirty

ninja explain: Core0-prefix/src/Core0-stamp/Core0-build is dirty

ninja explain: Core0-prefix/src/Core0-stamp/Core0-rescan is dirty

ninja explain: Core0-prefix/src/Core0-stamp/Core0-forcebuild is dirty

ninja explain: Core0 is dirty

=> "full" log is attached

=> everything in the Core0-stamp folder is an empty file, generated by CMake

I get the same output, when running the compilation without processing header-file dependencies (see 2nd attachment). Only the cmake steps 4/5  resp. 7/8 are switched.

In this case (without header deps processing) the incremental build works properly for c-files. 

Has somebody an idea why it's always rebuilding when processing header deps?

To unsubscribe from this group and stop receiving emails from it, send an email to ninja-build...@googlegroups.com.

[Harald Spiertz]

After further examinations, I have found that the syntax of the dep-files generated by the compiler is actually the reason for the problem described above.

I took the GCC compiler as a reference and compared its ninja_dep file with that of the other compiler. While the cross-compiler rebuilds any object which has a header dependency (even if there is no change), gcc works properly.

The comparison is attached.

Now I have the following question:

Is there a way to manipulate .ninja_deps or the dependency files of the compiler?

I was thinking about a script that adapts the dep-file of the compiler to the correct syntax before it is transferred to the ninja dep database. Maybe with a cmake ExternalProject_Add_Step ? ....

Does somebody has any idea?

BR / Harald

[Evan Martin]

Two options:

1) Maybe the cross-compiler emits some standard variant of the Makefile syntax that Ninja is failing to parse correctly, and it's just a bug in Ninja to be fixed;

2) Or, you can wrap your compiler with a shell script that runs your compiler, then fixes up the depfile into the right format, and then have Ninja use your substitute compiler.

To unsubscribe from this group and stop receiving emails from it, send an email to ninja-build+unsubscribe@googlegroups.com.

[Evan Martin]

Also, if you're having difficulty capturing the depfile produced by your compiler (to analyze if you're in case one), one trick is to run your build with

  ninja -v

which will cause it to dump the full command lines that it's running.  Then you can copy'n'paste one of the compilation command lines to run it manually to see the output files.