Added 'defines.json' for arbitrary macro definitions

[bogdanm]

This commit introduces 'defines.json' as a way to define arbitrary C/C++ macros in applications. This is needed for easier integration with 3rd party code that doesn't use yotta's convention for naming configuration-related macros (YOTTA_CFG_macroname).

[bogdanm]

@thegecko @marcuschangarm

[LiyouZhou]

Why another file, not a section in config.json?

[bogdanm]

Backward compatiblity mostly. Also, this isn't really configuration in the regular yotta sense, it's another form ("ad-hoc" configuration).

[bremoran]

Scattering configuration all over the place makes the whole system harder to use. Let's refrain from ad-hoc configuration. I agree with @LiyouZhou; it should be a section in config.json. If you really want to have it held in another file for compatibility with other build systems, then allow the config.json section to bring in an arbitrary json file instead of requiring a specially named file in yotta projects and scattering config all over.

[ilg-ul]

Did ARM decide to revive this project, frozen since May 2016?

[bremoran]

Also, please remember that Yotta is not a C/C++ build system. It happens to handle C/C++ and we happen to be using C/C++, but that doesn't mean it's the only thing out there. Using a defines file like this means that we have to work out what to do for other, arbitrary languages. Maybe it would make more sense to add a "project config file" option to the config.json and let each target work out what to do with that.

In the case of C/C++, the project config file would be a C/C++ include file that would be force-included.

[bogdanm]

it should be a section in config.json.

There's no way to do that in a backward-compatible way without using "magic" key names in config.json, since config.json can have configuration on more than one level, see for example http://yottadocs.mbed.com/reference/config.html#control-dependencies. Because of that, and because this is indeed a different kind of configuration, I maintain that it is a good idea to keep in a separate file. It might be scattered, but at least it makes the intent clear, and it might even make people think twice about using it (which is exactly the intention).

[bogdanm]

Also, please remember that Yotta is not a C/C++ build system.

At the moment, it is, and people are using it for C/C++ code. And the build system is pretty deeply embedded in yotta. Even if it wasn't, this is a completely optional feature (your application don't have to have a defines.json to work).

[marcuschangarm]

@bogdanm

Looks good to me.

Out of curiosity, how difficult would it be to follow the "target" separation in use by yotta?

[bremoran]

I've been thinking about how different languages would handle defines, and it's more common that compilers handle command-line definitions than that they handle things like force includes, so that probably maps to a larger proportion of languages, however, I still think that this belongs in one of the existing yotta input files, rather than a new one.

If any module can add defines, then it should go in module.json. If only targets and top-level programs can add defines, then it should go in config.json.

[bogdanm]

If any module can add defines, then it should go in module.json.

I could put it in module.json, but that'd mean that I just moved the C/C++ specific part somewhere else, not that I got rid of it. Also, I'm really not sure why we're talking that much about other languages. It's yotta itself that writes yotta_config.h, not the targets. It already knows quite a bit about C/C++.

[bremoran]

I think this is the right solution for now.

[autopulated]

Would un-prefixing the config be an option? (In parallel, I guess, to avoid breaking)

It would probably have been better if using a yotta prefix in config definitions had been a convention, rather than enforced, but hindsight eh.

[bremoran]

@autopulated wouldn't that cause namespace clashes?

[autopulated]

Yeah hence the convention of including the prefix – but you could break the convention if you really needed to. Just a thought!