Trying to add GCC support breaks the Keil microvision compatibility

[fred-r]

Hi,

I am currently trying to add the GCC support in my target clayer:

but when I do this and open the generated cprj file with Keil microvision 5.32 I get these elements in the uvprojx:

      <Cads>
        <interw>1</interw>
        <Optim>2</Optim>
        <oTime>0</oTime>
        <SplitLS>0</SplitLS>
        <OneElfS>1</OneElfS>
        <Strict>0</Strict>
        <EnumInt>0</EnumInt>
        <PlainCh>0</PlainCh>
        <Ropi>0</Ropi>
        <Rwpi>0</Rwpi>
        <wLevel>3</wLevel>
        <uThumb>0</uThumb>
        <uSurpInc>0</uSurpInc>
        <uC99>0</uC99>
        <uGnu>0</uGnu>
        <useXO>0</useXO>
        <v6Lang>3</v6Lang>
        <v6LangP>3</v6LangP>
        <vShortEn>1</vShortEn>
        <vShortWch>1</vShortWch>
        <v6Lto>0</v6Lto>
        <v6WtE>0</v6WtE>
        <v6Rtti>0</v6Rtti>
        <VariousControls>
          <MiscControls>-g3 -Wall -fstack-usage --specs=nano.specs -mfloat-abi=hard</MiscControls>
          <Define>USE_HAL_DRIVER STM32L562xx</Define>
          <Undefine></Undefine>
          <IncludePath>../../../../Drivers/BSP/STM32L562E-DK/;../../../../Drivers/STM32L5xx_HAL_Driver/Inc/;../../../../Drivers/STM32L5xx_HAL_Driver/Inc/Legacy/;../../../../Drivers/CMSIS/Device/ST/STM32L5xx/Include/;../../../../Drivers/CMSIS/Include/;./Targets/STM32L562E-DK/;.</IncludePath>
        </VariousControls>
      </Cads>

This leads to compilation errors because it seems that the tool tries to use the GCC definitions:

compiling sample_status.c...
ArmClang: error: unknown argument: '-fstack-usage'
compiling main.c...
ArmClang: error: unknown argument: '-fstack-usage'

Thanks & Regards,
Fred

[fred-r]

clayer file
STM32L562E-DK.zip

[jkrech]

Hi Fred, please note that uVision CPRJ support is limited to ArmCompiler 5 and 6 only. We shall make this clear in the documentation and add proper error message for that.
Sorry for the inconvenience.

[fred-r]

Hi Joachim,

do you mean that we cannot have a cprj with multiple compilers support ?
What I would like to do is to have one single cprj supporting AC6, IAR and GCC.

Then I may create a makefile with cbuildgen like:
cbuildgen make ${PROJ_NAME}.cprj --toolchain=GCC --outdir=BUILD --intdir=BUILD
cbuildgen make ${PROJ_NAME}.cprj --toolchain=ac6 --outdir=BUILD --intdir=BUILD

Or open the very same cprj with Keil uVision.

Do you mean that this will not be supported ?
Keil uVision cannot just ignore the other compilers directives ?

Thanks & Regards,
Fred

[jkrech]

a) Today Keil uVision reads a cprj file and converts it to a uvprojx file. In addition uVision can export one project target into a cprj file which by definition is for a single toolchain. Therefore the information for other toolchains are lost during import.
b) The cprj format's current design does support multiple toolchains within one cprj file however we don't have a tool that would maintain the settings in parallel. Note that "ignoring other compilers" get the projects easily out of sync.

One idea we are currently investigating is an approach where each CPRJ file only supports a single "configuration" meaning one toolchain but also one optimization setting (Debug vs. Release). These CPRJ files are then "orchestrated" using an umbrella description file. More advanced tools would be able to manage a consistency of a CPRJ files under one umbrella where as simple tools would leave the alignment between the "configurations" to the user / script etc.

Any other ideas are welcome as well.

Regards,

Joachim

[fred-r]

Hi Joachim,

IMHO a valuable asset of the current CPRJ definition is the possibility to support multiple comilers and settings in the very same file. Creating one CPRJ per compiler and settings would lead to an "uncontrolled" increase in the number of files, leading to difficult maintenance (need to duplicate the common content and keep it in sync).

At first sight, I do not understand why Keil uVision cannot check the compiler information in the cflags and as/ld directives:
<cflags .... compiler="GCC"/>

The piece of information we need is present.
Would you mind elaborating a bit more on the rationale to remove the possibility to support multiple compilers and settings in the same CPRJ file ? This feature looks really interesting to me.

Thanks & Regards,
Fred

[jkrech]

Hi Fred,
sorry for the lack of response on this.
I see why you consider concurrent multi-compiler support as a strength of the format, especially when dealing with "generated" reference projects rather than maintaining a project throughout multiple release cycles supporting multiple compilers.
What I am afraid of is setting people's expectation that the file format supports multiple concurrent compilers however once the file is loaded and modified by an IDE the stored project file will have either the compiler settings for all other compilers stripped off or running the risk of settings between tool-chains running out-of-sync. People may expect to have tools that maintains a cprj file with multiple compilers, which in my opinion isn't straight forward.
The other problem we have been facing during our tests is that tool-chain specific config files often use the same filename which will result in build failures (e.g. startup assembly files).
Regards,
Joachim