Release build not defining compiler

[Dave Jones]

Posted on March 29, 2018 at 22:22

I am using the latest TrueStudio with a project for STM32L452 created using the latest STM32CubeMX.

The created project contains both a debug and a release build. When I set the debug as active and look in one of the files that contains conditional compiles based on the compiler (core_cm4.h) I see that the lines for __GNUC__ are not grayed out. So obviously that compiler is defined somewhere.

However when I set the release build as active and look at that same file, all the conditional statements based on compiler are grayed out, and the final 'else' for 'unknown compiler' is the one not grayed out. So clearly __GNUC__ is not being defined anywhere.

Also, when I go to the build settings and select the release build I see a warning at the top that says 'Orphaned configuration. No base extension cfg exists for com.atollic.truestudio.exe.release.1518366166'. I don't get that when I select the debug build.

So, what does that warning actually mean, and why is the compiler not defined in the release build? (and where is it normally defined?)

[Markus Rudolf]

It's more than 3 Months and still not fixed in CubeMX 5.10. Instead of making a fancy new GUI no one really likes you should concentrate on making the tool fit for everyday use. This bug is annoying and shows internal testing could not be very intense when even such basic stuff does not work.

I would really like to have a proper bug tracking ticket system instead of this forum based approach. There is only a handful of moderators stating bugs are reported but you rarely get feedback if it's fixing, under which ticket ID the case is reported and so on.

[alister]

@Imen DAHMEN​ and @WBOUG​ you'd posted 3 months ago this would be fixed and @Markus Rudolf​ reports it isn't. So there's a disconnect. Can you describe at least what was fixed please?

[alister]

I too observe STM32CubeMX unnecessarily taints the project files of IAR and TS. Best practice, after regenerating a configuration, is to diff the project files and correct by hand any damage, same as for merge conflicts.

[WBOUG]

Hi @alister​ @SZank​ @Markus Rudolf​ @Yukiyo Watanabe​ @Community member​ 

This problem is fixed already and it will be found in version 5.2.0 CubeMX.

Best Regards,

Wael

[Markus Rudolf]

Any idea about a release date? I have some deadlines to meet with my current project....

[WBOUG]

It will be Q2

[Markus Rudolf]

Hmm thats worst case end of May... Is there a procedure to manually fix the configuration? I'm very confused by all the different XML Files, can someone explain me which sections I have to copy where to get a working config?

[alister]

That challenge is significant effort. I repair by continuous version control and fixing problems as they arises by diff with the previously working version and in context of what changed in the .ioc.

Simplest example: say you change only the pull-up/-down of a GPIO, you know it needn't make any change to the project files. Be suspicious if it has. You may revert them.

[Markus Rudolf]

@alister​ I think you got me wrong. The conversion of the project itself kinda works OK. I'm also not expecting many more iterations with the MX tool and regenerating code as the pinout and initialisation is already working okish.

The question was how to fix the error for the release build in the .project and .cproject files I guess.

I can actually change between debug and release build, the _DEBUG_BUILD define gets evaluated by the syntax highlighting e.g.

#ifdef _DEBUG_BUILD
  SEGGER_RTT_printf(0,"Tatkamera IF Board alive (DEBUG Build, GIT Version: %s)\r\n",GIT_HASH);
#else
  SEGGER_RTT_printf(0,"Tatkamera IF Board alive (RELEASE Build, GIT Version: %s)\r\n",GIT_HASH);
#endif

greys out the lower part on DEBUG build and greys out the upper part on a RELEASE build. In the debug and release folders I find in both cases a binary file that has the RELEASE printf text compiled in and they are both binary identical. I could live with both builds using the same optimizer settings for now, but I have conditional code that does for instance CRC checking of the flash in the RELEASE build which is not supposed to be compiled into a DEBUG build because it would not give the correct checksum (which I do after linking with some srecord tool foo, so its not in the downloaded ELF file)

That is my main problem right now.

[Markus Rudolf]

Simplest example: say you change only the pull-up/-down of a GPIO, you know it needn't make any change to the project files. Be suspicious if it has. You may revert them.

@alister​ That would imply there was actually a working version of the .project and .cproject files which to my knowledge is never the case. Even a fresh project shows the errormessage in the header of this post about the orphaned config. I have everything in GIT and can try go to the different versions but I doubt I will find something that works.