make example app generation optional

[mterber]

Is your feature request related to a problem? Please describe. Today, the blech compiler generates an example application file by default on each build. This leads to problems when the blech compilation phase is integrated into a C compilation process from an IDE for instance. The compilation process triggered by the IDE throws errors because there are two C files that implement a main() function – the actual user application main file and the example application generated by the blech compiler. In order to solve this you have to explicitly flag the example application file as "excluded from build" within the IDE.

Describe the solution you'd like I would suggest that the blech compiler only generates the blech example application file if a certain command line option is set. So by default, the blech compiler only generates the C code from the blech sources but does not generate the example application. This would be also in line with other compiler, e.g. gcc, which does not generate any example application too.

[frameworklabs]

For this other issue (https://github.com/boschresearch/blech/issues/16) I am planning to change the implementation so that only when the command line option '--trace' is provided, the printState() method is generated.

I am wondering if this option should also enable the generation of the "test-main" as it is there primarily to print the traces.

[FriedrichGretz]

I believe you are right: we use the auto generated main program "blech.c" if and only if we want to run the code and look at its trace.

There are two compiler flags at the moment "--trace" and "-app ". The latter changes the default name "blech.c" into whatever the user specifies.

If we decide to make "--trace" a switch for generating the printState function and a main program, then the "--app" option should only be permitted when "--trace" is set.

[schorg]

If we later on get a printf or something like that, an auto generated main program can also be useful without trace output. So these switches could be independent. If trace is on, printState should be part of the auto generated main program.

Also, I think, we would need subcommands and more complexity in the commandline handling (done with the Argu library) if we introduce dependent options.

[frameworklabs]

Maybe having a printState function would be interesting even in the case you want to provide your own app.

What about:

• -- printState (format) (if provided will generate printState() functions - currently json format only)
• -- app (name) (if provided will generate test-app named "name.c" - defaults to "blech.c")
• -- trace (format) (if provided together with --app, will implicitly set --printState format and generate printState() calls in the test-app)

So, to have the same output as today you would have to provide:

blechc --app --trace ...

?

[schorg]

I think there is no need for a --printState option.

• blechc --trace , generated the printState function(s)
• blechc --app <name>, generate the test-app without calling printState.
• blechc --app --trace, generate both and call the printState function in the test-app

Since we plan to have debug and release code later on, trace may become a configuration parameter for debug code.

With the module system and separate compilation it might become necessary to have a printState function for every activity.