mbed-cli support for .mbedignore file definition in mbed_app.json

[JanneKiiskila]

We have a situation that some of our configuration requires this kind of .mbedignore file and some other ones require a slightly different one.

Right now you can already say to mbed-cli with mbed_app.json file to use, but you can't give it the .mbedignore -file. We should either have the option to define that as well --ignore <thisfileas .mbedignore> OR alternatively add a config to the mbed_app.json file itself which would point to the relevant .mbedignore -file.

I know there is a differing view as well that we should not use the .mbedignore -files at all, but a) until that perfect day arrives, we have to live somehow - manually copy pasting .mbedignore -files is not a good solution b) compiling with Windows -machines at least is so slow, that every file you can get OUT of the compilation is a big win. I'm still dumbfound how much slower Windows 10 is compiling the exactly same app compared to a virtual machine running Ubuntu 16.04 on the same laptop.

So, how should it work then? .json parameter -option.

I have files under

/configs/this_config.json
         that_config.json
         this_ignore
         that_ignore

The _config.json -files would have a JSON parameter indicating the .mbedignore-file to use, this_config.json would refer to this_ignore and that_config.json to that_ignore.

Using the --profile -option with that_config.json would imply that the compilation would be similar as if

• that_config.json was in the / -folder as mbed_app.json AND
• that_ignore -file was in the / -folder as .mbedignore.

Same way with the extra option --ignore or similar, but I think the .json approach would yield a slightly simpler usability from end-user point of view.

Addition / 15-Dec-2017:

• may be self-evident, but if there are existing mbed_app.json and .mbedignore -files in the / -folder, we should not harm them in any way.

[JanneKiiskila]

Related items;

https://github.com/ARMmbed/atmel-rf-driver/issues/59 AND https://github.com/ARMmbed/stm-spirit1-rf-driver/issues/1

This problem is not going away too soon, unfortunately

[screamerbg]

cc @theotherjimmy

[JanneKiiskila]

@screamerbg - can you get this moving, please?

[screamerbg]

This is a build system question. cc @theotherjimmy @sg-

[theotherjimmy]

We should either have the option to define that as well --ignore <thisfileas .mbedignore> OR alternatively add a config to the mbed_app.json file itself which would point to the relevant .mbedignore -file.

This is not something I would like to see. I see this as yet another way that the files in a build would change.

We have a situation that some of our configuration requires this kind of .mbedignore file and some other ones require a slightly different one.

Could you share that situation?

Using the --profile -option with that_config.json would imply that the compilation would be similar as if that_config.json was in the / -folder as mbed_app.json AND that_ignore -file was in the / -folder as .mbedignore.

This is not how the --app-config parameter works right now, and I don't know what the --profile option is doing in that sentence. The --app-config parameter does not pretend that it's argument was found in the root, instead it treats the file specified as the application configuration. When the parameter to --app-config contains file names, they are relative to the location of that file not to the project root. An ignore file would need to pretend to be in the root, and would not be consistent with this behavior.

---

Have you considered using extra_labels?

[screamerbg]

Bump @JanneKiiskila

[NeilMacMullen]

FWIW I would also like the ability to change the subset of compiled files depending upon configuration. My scenario is that I wish to compile both a minimal bootloader and an application from the same codebase. There is a small amount of shared code but the 'feature set' is very different between the two builds and I don't want the bootloader dragging in all the unused features. More generally, I may want to build different platform variants with different features sets from the same application code base in future.

cc'ing @MarceloSalazar since he was involved in some discussion around this.

[JanneKiiskila]

@adbridge - a little bit more guidance needed?

[adbridge]

@JanneKiiskila Apologies, the comment is from our new automated issue checking script that got rolled out yesterday. Unfortunately it looks like I missed some configuration in a number of repos. I will fix it :)

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-68

[mcheah-bose]

I assume this issue is effectively dead, but has anybody come up with an easy way to do conditional compilation of features in mbed? I saw another thread where somebody had proposed a custom Makefile, which IMO defeats the purpose of mbed being a quick way to organize and build projects. In my particular case I have two copies of mbed-os, one being a development branch from the chip vendor for an early silicon revision, and the other being the main mbed-os branch for mainstream processors. Keeping two copies of the project just to compile different targets is somewhat of a drag and I don't want to go through the manual effort of merging the Vendor's changes back into the main mbed branch.

[40Grit]

I agree regarding the desire for conditional compile/build.

Best option I have found is buckaroo 2.0 for package managment. I have no good solution build wise.

[0xc0170]

Best option I have found is buckaroo 2.0 for package managment. I have no good solution build wise.

@40Grit Can you elaborate about build wise?

[40Grit]

Im referring to the fact that I do not know of a good alternative to make nor the build scripts that are part of mbed-os/tools.

[ciarmcom]

Thank you for raising this issue. Please note we have updated our policies and now only defects should be raised directly in GitHub. Going forward questions and enhancements will be considered in our forums, https://forums.mbed.com/ . If this issue is still relevant please re-raise it there. This GitHub issue will now be closed.