Topic : How to remove __FILE__ path?

Forum : ST7/STM8

Original Post
Post Information Post
May 2, 2016 - 8:48am
Matthieu Tardivon

Hello,

We are working with Ride 7 with an STM8 MCU and we are having some trouble with the preprocessor variable __FILE__.According to our tests, the __FILE__ variable seems to contains the first argument of the command with RCSTM8.EXE. Unfortunately, the IDE uses the full path to the C file and the generated Makefile uses the relative path to the C file.

This is not very portable as the executable generated locally by the developer will be different from the one built on our build server, which can have huge impacts on the tests.

Is there a way to configure the compiler to replace __FILE__ by only the name of the file? Otherwise, can you consider it for your next release?

Best wishes,

Matthieu Tardivon
Replies
Post Information Post
+1
+1
-1
May 3, 2016 - 12:59pm
Stéphane CLOG

Hello,

The next version will provide the new pragmas nopathinmacros and pathinmacros that will give the ability to have the __FILE__ and __BASE_FILE__ predefined macros stripped from their path or not.

Regards,

Stéphane
+1
0
-1
May 3, 2016 - 11:04am
Stéphane CLOG

Hello Matthieu,

Unfortunately is won't be possible to modify the __FILE__ behavior. On all compilers it expands to the full filename and this kind of change can broke the way other users are using it.

You can use this macro:

#define __FILENAME__ (strrchr(__FILE__, '/') ? strrchr(__FILE__, '/') + 1 : __FILE__)

Regards,

Stéphane
+1
0
-1
May 3, 2016 - 11:55am
Matthieu Tardivon

Hello,

strrchr being a function and not a macro, this does not solve the portability issue unfortunately.

I don't get why it can't be possible to modify the __FILE__ behaviour. For example, IAR proposes an option --no-path-in-file-macro which if enabled truncates the path.

This is the kind of flexibility I expect from Raisonance as well.

When testing SW in debug in embedded systems, it is very important that developers and testers can reproduce the same compilation to validate the SW. It is all the more important when working with medical device, which is our case.

As you can imagine, we can't afford to kill a patient in a clinical trial because the path on the build server was too long and for some reason it changed the SW behaviour in an unexpected way as it had not been fully tested in this precise configuration.

Thank you for your support,

Matthieu Tardivon
+1
0
-1
May 3, 2016 - 1:25pm
Matthieu Tardivon

Hello,

Thank you very much for your support and understanding, I am looking forward to the next release.

Best regards,

Matthieu Tardivon