Ninja keeps starting cmake

[Pierre-Nicolas Rigal]

Hello,

I just moved to OSX 10.9, and decided to upgrade my build box. I was using mac ports, but following some colleagues advices, I moved to homebrew. Therefore I upgraded both cmake (2.8.12) and ninja ( moved to 1.4.0 ). After struggling a bit with the changes introduced with XCode 5.0.1 and 10.9, I've now a running build system ( I'm using Qt 4.8.5 + Qt Creator).

Everything seems to work fine, except that calling ninja will re-run cmake even if no there is no change in the code, which leads to re-link all executables in my project ( including the 100+ unit tests...), which is a bit bad ( it takes 12 seconds using make, 25 using ninja...)

any idea about what could be the reason for this, or any hint on what I could do to track what's going wrong ?

thanks in advance.

regards,

Pn

[Scott Graham]

You could try running ninja with "-d explain" which might illuminate why cmake is getting re-run.

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Matthew Woehlke]

In general: 'ninja -d explain' to see why ninja thinks it needs to do
something (re-run cmake, in this case).

I suspect that this isn't Ninja's fault, but rather CMake's fault or the
fault of the project you are trying to build.

Did you try with some other CMake-based project? This would be a good
indication if the fault is CMake itself of the specific project you are
building.

--
Matthew

[Nico Weber]

What does `ninja -d explain` print?

--

[Pierre-Nicolas Rigal]

Hi - and thanks for the answers.

So:

$ ninja -d explain -v

ninja explain: output build.ninja older than most recent input /Users/pnr/github/master-build/bin/xxx.app/Contents/MacOS (1382557340 vs 1382557345)

[1/1] /usr/local/Cellar/cmake/2.8.12/bin/cmake -H/Users/pnr/github/master -B/Users/pnr/github/master-build

and:

[pnr@pnr master-build]$ ls -lT build.ninja

-rw-r--r--  1 pnr  staff  4160361 23 oct 21:21:45 2013 build.ninja

[pnr@pnr master-build]$ ls -lT /Users/pnr/github/master-build/bin/xxx.app/Contents/MacOS

total 54432

-rwxr-xr-x  1 pnr  staff  27866012 23 oct 21:21:49 2013 xxx

[pnr@pnr master-build]$

so it looks like one file is now built / created after build.ninja is getting updated.

if I'm doing : ninja && touch build.ninja, it works as expected, i.e. superfast "nothing to rebuild" run.

I tried the following:

ninja -d explain && date

I get: Mer 23 oct 2013 22:42:38 CEST

and if I do at the same time sudo opensnoop -v -f build.ninja

2013 Oct 23 22:42:21   501  98860 ninja          3 build.ninja

so the build ends at 22:42:38, but the last time buid.ninja has been open is at 22:42:21.

Not sure how to force ninja to update build.ninja only at the end.

Thanks & regards,

pn

[Nico Weber]

Ninja doesn't update build.ninja itself, there's some rule (written by cmake?) that tells it to run something that updates it. You might be able to run `ninja -t commands build.ninja` to see the command that does this. You can run `ninja -t query build.ninja` to see the inputs for this rule – it looks like one of your build products is somehow an input for your build file?

Maybe one of the cmake folks understand what's happening here.

--

[Matthew Woehlke]

On 2013-10-23 16:49, Pierre-Nicolas Rigal wrote:
> $ ninja -d explain -v
> ninja explain: output build.ninja older than most recent input
> /Users/pnr/github/master-build/bin/xxx.app/Contents/MacOS (1382557340 vs
> 1382557345)

Hmm... apparently this file is generated by the build(?), but CMake
believes that the build rules depend on this file and so has generated a
configure dependency on it.

Do you get the same behavior with other CMake-based projects? Can you
look if any CMake code (e.g. in a CMakeLists.txt) is referring to this file?

> Not sure how to force ninja to update build.ninja only at the end.

build.ninja should be created by CMake, and otherwise not updated by the
build process.

Again, this looks suspiciously like there is a problem in the CMake
logic for this specific project that is causing it to have a configure
dependency on a build artifact.

--
Matthew

[Pierre-Nicolas Rigal]

All,

a colleague encounter the issue : he upgraded cmake to 2.8.12 too. So it seems it's related to 2.8.12 version. I cleaned my environment and reverted to 2.8.10 (yay! for homebrew), and it seems to be working correctly now.

Trying to look at build.ninja file : it was regenerated each time. things that moved were mainly related to moc files (we're using Qt) ; so I looked at cmake bug tracker, a couple of issues related to automoc, including: http://public.kitware.com/Bug/view.php?id=14379 . could it be this one that leads to our issue ?

anyway, seems that ninja is not guilty :).

Thanks for the really fast and friendly support !

Pn

Le mercredi 23 octobre 2013 21:16:59 UTC+2, Pierre-Nicolas Rigal a écrit :

[Bill Hoffman]

On 10/25/2013 4:09 AM, Pierre-Nicolas Rigal wrote:
> All,
>
> a colleague encounter the issue : he upgraded cmake to 2.8.12 too. So it
> seems it's related to 2.8.12 version. I cleaned my environment and
> reverted to 2.8.10 (yay! for homebrew), and it seems to be working
> correctly now.
> Trying to look at build.ninja file : it was regenerated each time.
> things that moved were mainly related to moc files (we're using Qt) ; so
> I looked at cmake bug tracker, a couple of issues related to automoc,
> including: http://public.kitware.com/Bug/view.php?id=14379 . could it be
> this one that leads to our issue ?
>
> anyway, seems that ninja is not guilty :).
>
> Thanks for the really fast and friendly support !
>

I would still like to figure out what is wrong with the CMake ninja.
Have you saved the build.ninja file before and after it changes to see
what changes? Also, can you send me the complete output of the build
that has the issue. CMake should announce that it is re-running.

Thanks.

[Bill Hoffman]

On 10/25/2013 4:09 AM, Pierre-Nicolas Rigal wrote:

> All,
>
> a colleague encounter the issue : he upgraded cmake to 2.8.12 too. So it
> seems it's related to 2.8.12 version. I cleaned my environment and
> reverted to 2.8.10 (yay! for homebrew), and it seems to be working
> correctly now.

Is your code open source and easy to build? It would be good to try
this out.

-Bill

[Peter Kümmel]

On 23.10.2013 22:49, Pierre-Nicolas Rigal wrote:
>
> $ ninja -d explain -v
> ninja explain: output build.ninja older than most recent input /Users/pnr/github/master-build/bin/xxx.app/Contents/MacOS
> (1382557340 vs 1382557345)

Looks like the file "MacOS" is generated after building build.ninja.
I assume it is also listed by "ninja -t query build.ninja".
Does the name look different to the existing path (final slash, quote, or something similar)?

I found this commit in cmake which has touched MacOS since 28.11:
https://github.com/Kitware/CMake/commit/483e208482ff46532e7ae48659e569580a88af9c

> [1/1] /usr/local/Cellar/cmake/2.8.12/bin/cmake -H/Users/pnr/github/master -B/Users/pnr/github/master-build
>
> and:
>
> [pnr@pnr master-build]$ ls -lT build.ninja
> -rw-r--r-- 1 pnr staff 4160361 23 oct 21:21:45 2013 build.ninja
> [pnr@pnr master-build]$ ls -lT /Users/pnr/github/master-build/bin/xxx.app/Contents/MacOS
> total 54432
> -rwxr-xr-x 1 pnr staff 27866012 23 oct 21:21:49 2013 xxx
> [pnr@pnr master-build]$
>
> so it looks like one file is now built / created after build.ninja is getting updated.
>
> if I'm doing : ninja && touch build.ninja, it works as expected, i.e. superfast "nothing to rebuild" run.
>
> I tried the following:
>
> ninja -d explain && date
>
> I get: Mer 23 oct 2013 22:42:38 CEST
>
> and if I do at the same time sudo opensnoop -v -f build.ninja
>
> 2013 Oct 23 22:42:21 501 98860 ninja 3 build.ninja
>
> so the build ends at 22:42:38, but the last time buid.ninja has been open is at 22:42:21.
>
> Not sure how to force ninja to update build.ninja only at the end.
>
> Thanks & regards,
> pn
>
>
>
>

> Le mercredi 23 octobre 2013 21:16:59 UTC+2, Pierre-Nicolas Rigal a �crit :

>
> Hello,
>
> I just moved to OSX 10.9, and decided to upgrade my build box. I was using mac ports, but following some colleagues
> advices, I moved to homebrew. Therefore I upgraded both cmake (2.8.12) and ninja ( moved to 1.4.0 ). After
> struggling a bit with the changes introduced with XCode 5.0.1 and 10.9, I've now a running build system ( I'm using
> Qt 4.8.5 + Qt Creator).
>
> Everything seems to work fine, except that calling ninja will re-run cmake even if no there is no change in the
> code, which leads to re-link all executables in my project ( including the 100+ unit tests...), which is a bit bad (
> it takes 12 seconds using make, 25 using ninja...)
>
> any idea about what could be the reason for this, or any hint on what I could do to track what's going wrong ?
>
> thanks in advance.
> regards,
> Pn
>

[Pierre-Nicolas Rigal]

Sorry, could not update for the week.

Actually, I'm using ninja/cmake on a closed source project, so unfortunately no way to give access to the code.

Nevertheless, I'll do my best to help figuring what's going wrong. If someone needs some files or more details and if it's ok to deal off list just let me know.

I just switched back to 2.8.12 and tried again.

I ran:

$ ninja -d explain

ninja explain: output build.ninja older than most recent input /Users/pnr/github/master-cmake2812/bin/xxx1.app/Contents/MacOS (1383570509 vs 1383570513)

I just ran it a second time, and I'm now getting:

$ ninja -d explain

ninja explain: output build.ninja older than most recent input /Users/pnr/github/master-cmake2812/bin/xxx2.app/Contents/MacOS (1383570600 vs 1383570604)

where xxx1 and xxx2 are 2 different apps that are built. Now I if run ninja again it will show the message regarding xxx2.

If I'm looking at the 2 cmakelist.txt files for these 2 apps, we have, for OSX, this common setup:

IF( APPLE )

    SET( BUNDLE_NAME "xxx" )

    SET( MACOSX_BUNDLE_ICON_FILE "xxx.icns" )

    SET(apple_bundle_sources "res/xxx.icns")

    SET_SOURCE_FILES_PROPERTIES( "res/xxx.icns" PROPERTIES MACOSX_PACKAGE_LOCATION Resources)

    SET( MACOSX_BUNDLE_BUNDLE_NAME ${BUNDLE_NAME} )

    SET( MACOSX_BUNDLE_INFO_STRING "${BUNDLE_NAME} ${xxx_ProductVersion}" )

ENDIF( APPLE )

Not sure if this is related.

The build.ninja file is completely rewritten each time I call ninja:

diff ../build.ninja build.ninja | wc -l
    3135

Looking randomly to the diff, I can see:

< build Testing/UnitTests/TestMobileInventoryModel/CMakeFiles/TestMobileInventoryModel.dir/TestMobileInventoryModel_automoc.cpp.o: CXX_COMPILER Testing/UnitTests/TestMobileInventoryModel/TestMobileInventoryModel_automoc.cpp || lib/libxxxGuiLib.a lib/libxxxLicenseLib.a lib/libxxxCoreLibTNG.a lib/libxxxAdminLib.a Testing/UnitTests/TestMobileInventoryModel/TestMobileInventoryModel_automoc
---
> build Testing/UnitTests/TestMobileInventoryModel/CMakeFiles/TestMobileInventoryModel.dir/TestMobileInventoryModel_automoc.cpp.o: CXX_COMPILER Testing/UnitTests/TestMobileInventoryModel/TestMobileInventoryModel_automoc.cpp || lib/libxxxLicenseLib.a lib/libxxxAdminLib.a lib/libxxxCoreLibTNG.a lib/libxxxGuiLib.a Testing/UnitTests/TestMobileInventoryModel/TestMobileInventoryModel_automoc

so the lib order seems to vary each time. Not sure it is something in our cmakelist file - files have a long history or a cmake 2.8.12 bug.

Again, I'd be happy to help, just not sure exactly how / where to look at.

Thanks,

regards,

Pn

[Peter Kümmel]

On 04.11.2013 14:26, Pierre-Nicolas Rigal wrote:
> Sorry, could not update for the week.
>
> Actually, I'm using ninja/cmake on a closed source project, so
> unfortunately no way to give access to the code.
> Nevertheless, I'll do my best to help figuring what's going wrong. If
> someone needs some files or more details and if it's ok to deal off list
> just let me know.

Thanks for the offer!

What prints "ninja -t commands build.ninja"? Any suspect files listed?

> Le mercredi 23 octobre 2013 21:16:59 UTC+2, Pierre-Nicolas Rigal a �crit :