mbed_app.json update does not mark build as dirty

[janjongboom]

1. Build a project.
2. Now change something in mbed_app.json

Expected: project gets rebuild

Actual: project does not rebuild. Need manually clean for changes to be picked up.

[0xc0170]

cc @bogdanm

[bogdanm]

Interesting, thank you. Currently, mbed_config.h is an implicit dependency for every source file that we compile (since the compiler includes it automatically using --preinclude), so if the configuration changes, the whole project needs to be rebuilt (which doesn't happen currently because we don't check at all if mbed_config.h changes). The only alternative to always rebuilding all the source files is for sources that actually need the configuration to include it explicitly, which is something we can probably consider. --preinclude is used currently for convenience (so that code has direct access to the configuration without having to include any headers), but we can change that if needed.

So, to recap, there are two ways to change this:

1. check if mbed_config.h changes between compiles (using hash sums) and recompile everything if it does (keeps the current --preinclude behaviour (convenience)).
2. require the code that needs configuration data to include mbed_config.h explicitly (removes the curent --preinclude behaviour).

Short term, 1 will work, but I'm wondering if 2 might be a better solution long term. @screamerbg @sg-, thoughts?

[0xc0170]

I was thinking about 2nd previously as --preinclude is convenient, but we found few shortcomings (iar asm preinclude as an example). The biggest disadvantage of the 2nd option is that we would need to add ìnclusion of mbed_config.h almost everywhere (I disregard including it in mbed.h, as that is for the application, but we need it within mbed SDK or other modules, in C or possibly asm). It is acceptable and should be done now now.

I would go for 2nd. Include it in the mbed.h for apps. Include mbed_config.h where it is required as it should be within mbed modules/repos. This would mean that config header should be present even though is empty, or at least protected via macro like MBED_CONFIG_ACTIVE (sounds better to go with former - the header always present).

[theotherjimmy]

What @0xc0170 Outlines sounds good to me. I'm going to start on the implementation of it. @bogdanm @0xc0170 , any thoughts before I do?

[bogdanm]

@theotherjimmy: that sounds just about right to me. To recap:

1. mbed_config.h is going to be automatically included by mbed.h
2. if HAL or other sources that don't include mbed.h need to access the configuration data, they'll need to include mbed_config.h manually.
3. if mbed_config.h doesn't exist for whatever reason, it'll be automatically created by the build system (as an empty file).

2. above might be a breaking change for some of our sources, but I think we need to go ahead and implement this anyway.

[bogdanm]

@theotherjimmy: let me know if you're already working on this; if not, I'll implement it.

[theotherjimmy]

@bogdanm I have not started yet, I got sidetracked.

[bogdanm]

OK, thank you. I'll work on this then.

[ciarmcom]

ARM Internal Ref: IOTMORF-147