Handling of preprocessor-defined strings in TRICE macro

[escherstair]

I found this situation while adapting my old printf source code to Trice.
Here there are useful information on how to handle strings.
I've just found another situation where a constant string is defined through a preoprocessor macro.
As an example
#define VERSION_STRING "1.0.0"
How should this be handled?
I tried with
TRICE("The version is:"VERSION_STRING);
but trice tool receives the message
The version is VERSION_STRING
and I think the reason is that as reported ion the User Guide,

string concatenation within TRICE macros is untested and expected not to work. The reason lays inside the way the update tool works (right now)

Which is the optimal way to handle this kind of strings (known at compile time) at the moment?
Thanks

In a long term roadmap, this could be an improvement of the update feature of the trice tool.

[rokath]

I would expect not working at all or The version is:VERSION_STRING in the given example. You can also have a look into the til.json. My recommendation:

#define MAJOR 1
#define MINOR 0
#define PATCH 0
TRICE8( "The version is: %d.%d.%d\n");

[escherstair]

In this case the workaround is ok, but imagine it's

#define DUMMY_STRING "this is a dummy string"

The C preprocessor can concatenate the strings in this way

printf("The string is:"DUMMY_STRING);

but I understand that trice tool (at the moment) doesn't play the role of the preprocessor.
And so

TRICE("The string is:"DUMMY_STRING);

doesn't concatenate the string.

[rokath]

The **trice ** tool cannot perform, what a preprocessor does. It is limited to simple string replacements. If you really need such string concatenation, you could try a 2nd trice update run on the preprocessor output. But I think it is not worth the effort and brings in difficulties with the ID handling. What about this:

#define DUMMY_STRING "The string is dummy string"
TRICE( DUMMY_STRING );

Then, before running trice u, use a text processor to replace DUMMY_STRING.

I cannot imagine the need for that. Would you please tell me more about the use case?

[escherstair]

@rokath I agree with you.
trice tool cannot do the job of a C preprocessor, and the proposed workaround it's not worth the effort.

This topic comes from a real job of replacing printf code into trice code.
Sometimes in C it's quite common using some #define to create compile-time-known items (strings, numbers, ...)
Usually they're kept into a .h file that can be changed to reconfigure the project with other parameters.
All this data is know at compile time (after preprocessing task, in reality) and so they could be optimized with trice.
But the effort is too high and it goes beyond the scope of trice tool.
I think that the best solution is to use them like dynamic strings or data (subotimal way, but we can live with it):

#define DUMMY_STRING "The string is dummy string"
#define MAGIC_NUMBER 3
...
TRICE_S( "msg:%s\n", DUMMY_STRING);
TRICE( "msg:The value of the magic number is %d\n", MAGIC_NUMBER);

[rokath]

Maybe you can write inside your header file

#include "trice.h"
#define DUMMY_STRING TRICE( "msg:The string is dummy string\n");

and in your C-file

void fn(void){
    DUMMY_STRING 
}

This could work but may cause difficulties with the location information what probably is solvable.

[rokath]

Pleas read https://github.com/rokath/trice/blob/master/docs/TriceUserGuide.md#97-dynamic-stringsbuffers-only-as-variable-inside-trice-macros-before-v0610 - now you can write TRICE_S( "name=%s\n", "Eva" );