partial rebuilding

[pelikhan]

If I execute python build.py immediately after itself, I would have expected a much faster build time. It seems to be rebuilding all the files all over again.

[finneyj]

Yes, this seems to be a windows feature - my build suffers from this also. Something in there is forcing a clean rebuild... @jamesadevine is it possible to test a ninja-less build with just cmake?

[jamesadevine]

Nothing forces a clean rebuild. The script enters the build folder and executes ninja.

[finneyj]

Is there a way to not use ninja though? As a means to honing in on the cause of the problem?

[jamesadevine]

Ah I see, you can use whatever build system you want...

cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo -G \"Ninja\"

Change Ninja to any other supported one listed here:

https://cmake.org/cmake/help/v3.0/manual/cmake-generators.7.html#command-line-build-tool-generators

There are not many options for windows, and make runs really slowly.

I imagine this is specific to ninja as partial rebuilding is supported on Mac using make.

ninja -d explain will help diagnose the cause.

[finneyj]

Ta. Yes, just looking. make doesn't run slowly compared to a clean rebuild all the time . ;)

I've just been digging and it seems to come down to one header file that (I guess) is being regenerated every build, which in turn makes everything look dirty. My windows logs are full of:

ninja explain: output libraries/mbed-classic/CMakeFiles/mbed-classic.dir/targets/hal/TARGET_Atmel/TARGET_SAM_CortexM0P/spi_api.c.obj older than most recent input C:/git/CircuitPlayground/codal/build/codal_extra_definitions.h (535300971 vs 535301080)
ninja explain: libraries/mbed-classic/CMakeFiles/mbed-classic.dir/targets/hal/TARGET_Atmel/TARGET_SAM_CortexM0P/spi_api.c.obj is dirty
ninja explain: output libraries/mbed-classic/CMakeFiles/mbed-classic.dir/targets/hal/TARGET_Atmel/TARGET_SAM_CortexM0P/us_ticker.c.obj older than most recent input C:/git/CircuitPlayground/codal/build/codal_extra_definitions.h (535300971 vs 535301080)
ninja explain: libraries/mbed-classic/CMakeFiles/mbed-classic.dir/targets/hal/TARGET_Atmel/TARGET_SAM_CortexM0P/us_ticker.c.obj is dirty
.
.
.

[finneyj]

I'll have a look to see if we can do something more optimised with that header file.

[jamesadevine]

ok - quick test then... Could you just run ninja in the build folder, and see if that partially rebuilds?

[finneyj]

already tried that - it doesn't rebuild, just relinks the final binaries...

Anything magical about "codal_extra_definitions.h" in the build process?

[jamesadevine]

Could you replace the similar looking code at line 175, with this:

# create a header file from the definitions specified in JSON
if("${CODAL_DEFINITIONS}" STRGREATER "")
    set(EXTRA_INCLUDES_NEW_PATH "${PROJECT_SOURCE_DIR}/build/codal_extra_definitions_new.h")
    set(EXTRA_INCLUDES_PATH "${PROJECT_SOURCE_DIR}/build/codal_extra_definitions.h")
    file(WRITE "${EXTRA_INCLUDES_NEW_PATH}" ${CODAL_DEFINITIONS})
    configure_file(${EXTRA_INCLUDES_PATH} ${EXTRA_INCLUDES_NEW_PATH} COPYONLY)

    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -include ${EXTRA_INCLUDES_PATH}")
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -include ${EXTRA_INCLUDES_PATH}")
endif()

And report back?

[finneyj]

yes, I was just looking slightly askew at that code. Will try now.

[jamesadevine]

It looks like make does its' diff process differently to ninja.

[finneyj]

yup - that fixes it for me.

[jamesadevine]

Great, will push.

[finneyj]

Thanks James.

[jamesadevine]

281e03d