Copying JSON files to pick up config for built libraries

[bridadan]

This came up when building tests, but affects any library using config that's first built, then included as "source" with the mbed tools. JSON files are not copied by default when building a library, so when this is built it loses the config data associated with the library. This commit copies all JSON files into the build directory when building libraries.

There is a strange side effect now which is there are now multiple mbed_config.h files created during the build process: one when building the library and one when building the actual application. This isn't currently a problem since none of our code explicitly includes mbed_config, but it does look strange. Is anyone aware of potential issues with this? If so, having the ability to prevent an mbed_config.h from being created in the API may be a solution.

cc @bogdanm @AlessandroA @screamerbg

[bridadan]

This should hopefully address one of the issues raised in #2397

[bridadan]

/morph test

[mbed-bot]

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 659

All builds and test passed!

[bogdanm]

There is a strange side effect now which is there are now multiple mbed_config.h files created during the build process: one when building the library and one when building the actual application.

The mbed_config.h file that is created when building the library needs to be deleted. The configuration system will generate a new mbed_config.h when building the application (and this mbed_config.h will take into account all the mbed_lib.json files that it finds in the source directories).

[bogdanm]

What happens if the scanner finds more than one mbed_lib.json file? For example, the one for core and the one forrtos. Are those copied in separate directories? It's important to keep all thembed_lib.json` files found by the scanner.

[bridadan]

I believe the paths for mbed_lib.json files should be preserved, though I will double check this!

[bridadan]

@bogdanm Thanks for the feedback. Perhaps the way we should do this then is provide an option to the build_library api that allows you to disable creating the mbed_config.h files? So when building tests, we would disable the creating of the file altogether.

[bogdanm]

So when building tests, we would disable the creating of the file altogether.

The thing is that when building you need mbed_config.h, since that's how the libraries know about their compile-time configuration. But that file is only needed when building the library; later, when the application is built, the config system will re-create mbed_config.h from the various mbed_lib.json files it finds, plus the mbed_app.json file. So either:

• when building the library, create the mbed_config.h file somewhere outside the library build tree.
• build the library, then remove the mbed_config.h file.

The second option above is probably a bit easier to implement.

[theotherjimmy]

We could always create mbed_config.h as a temp file. That would accomplish both of those points at the same time. OTOH, I think it's reasonable to insist that library builds always delete the mbed_config.h

[bridadan]

I've added an option to build_library that allows you to remove the config header file after compilation completes. This is by default disabled, but I enable this when building tests.

[bridadan]

/morph test

[theotherjimmy]

Instead, could you possibly delete the mbed_config.h after you call build_library? I'm hesitant to increase the number of arguments to build library, it's already ~20.

OTOH, 👍 on the docstring update.

[bridadan]

@theotherjimmy I did think about doing that. Although in test.py I don't have access to the toolchain instance and I was using that to get the location of the mbed_config.h header. I could probably search through the build directory to find it (or just assume its at the root of the build directory), but that seemed a bit presumptive. What do you think?

[theotherjimmy]

I don't like it, but you're right it would be hacky either way.

[mbed-bot]

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 689

Test failed!

[AlessandroA]

@theotherjimmy @bridadan What's the status of this?

[bridadan]

@bogdanm Are you happy with this?

[0xc0170]

@bogdanm Are you happy with this?

He's away for the next days. We shall together review and do +1 if it looks good and addresses comments within this patch. @theotherjimmy happy with this?