Too many messages

[edwardalee]

Recent changes in message reporting (#1527) have resulted in a large number of not-very-useful messages being printed when running lfc. E.g., here is the tail of the output from running lfc on a C program:

...
[ 97%] Building C object CMakeFiles/Rhythm.dir/audio_loop_mac.c.o
[100%] Linking C executable Rhythm
[100%] Built target Rhythm
Install the project...
-- Install configuration: "Release"
lfc: info: ******** generated sources: /Users/eal/git/examples-lingua-franca/C/src-gen/rhythm/Rhythm


lfc: info: ******** mode: STANDALONE


lfc: info: Compiled binary is in /Users/eal/git/examples-lingua-franca/C/bin


lfc: info: Copied '/lib/c/reactor-c/util/audio_loop.h' from the class path.


lfc: info: Copied '/lib/c/reactor-c/util/audio_loop_linux.c' from the class path.


lfc: info: Copied '/lib/c/reactor-c/util/audio_loop_mac.c' from the class path.

Code generation finished.

lfc: info: Copied '/lib/c/reactor-c/util/sensor_simulator.c' from the class path.


lfc: info: Copied '/lib/c/reactor-c/util/sensor_simulator.h' from the class path.


lfc: info: Copied '/lib/c/reactor-c/util/wave_file_reader.c' from the class path.


lfc: info: Copied '/lib/c/reactor-c/util/wave_file_reader.h' from the class path.


lfc: info: Generating code for: file:/Users/eal/git/examples-lingua-franca/C/src/rhythm/Rhythm.lf


lfc: info: SUCCESS: Compiling generated code for Rhythm finished with no errors.



Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/8.1.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 5s
20 actionable tasks: 1 executed, 19 up-to-date

Are all these lfc: info info messages really needed? If so, do we need all that whitespace between them?

[lhstrh]

At least some of these message could be classified as "debug" messages. We could treat them as such and hide them unless a --verbose or --debug switch is used...

I agree that we don't need the extra newlines.

I also think that, generally, we could clean up the messages and make them look more uniform (like eliminating the leading asterisks). Also see #558.