CMake on STM32 | Episode 3: handle warnings in 3rd party files

Something funny happens sometimes with 3rd party files: they generate warnings when compiled with your project settings. If you have quality indicators about the build health (automatically updated by Jenkins maybe), this is quite annoying. If you compile with an option such as -Werror to treat warnings as errors, this is a blocking issue.

In this article, we will add compiler options that will raise warnings in ST's generated files and we will ask CMake to suppress these warnings but only for these files.

Add compilers options

In episode 1, we simply used the compiler options from ST's generated Makefiles. The only option to control GCC warnings is -Wall. If this is not clear for you yet, I will say it very clearly : -Wall does not enable all warnings and compiling with -Wall is not enough. I suggest that you use at least -Wall -Wextra. This GitHub repository has lists of options to enable warnings. You might be scared ^^

For the example here, let's add -Wextra -pedantic. Simply modify the call to target_compile_options() in CMakeLists.txt:

target_compile_options(${EXECUTABLE} PRIVATE
        -mcpu=cortex-m4
        -mthumb
        -mfpu=fpv4-sp-d16
        -mfloat-abi=hard

        -fdata-sections
        -ffunction-sections

        -Wall
        -Wextra
        -pedantic

        $<$<CONFIG:Debug>:-Og>
        )

When you recompile the project, you will see warnings that you didn't get before:

[ 48%] Building C object CMakeFiles/nucleo-f413zh.out.dir/BSP/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_pwr.c.obj
D:\cmake_stm32\BSP\Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_pwr.c: In function 'HAL_PWR_EnterSLEEPMode':
D:\cmake_stm32\BSP\Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_pwr.c:365:38: warning: unused parameter 'Regulator' [-Wunused-parameter]
  365 | void HAL_PWR_EnterSLEEPMode(uint32_t Regulator, uint8_t SLEEPEntry)
      |                             ~~~~~~~~~^~~~~~~~~

Change compiler options for a specific file

At this point, we are facing a dilemma:

1. It is out of the question that we modify generated / 3rd party files.
2. There is no way that we remove -Wextra (that adds -Wunused-parameter).

We may add -Wno-unused-parameter to target_compile_options() to counter -Wunused-parameter. It will suppress the warnings on ST's generated file but also for our own files. This is not what we want because it would be useful to be warned if a function we wrote doesn't use one of its parameters.

The solution is to add -Wno-unused-parameter only to these generated files. Our own code will then still compile with -Wunused-parameter.

The CMake function to do this is set_source_files_properties().

We modify our CMakeLists.txt again to add this:

set_source_files_properties(BSP/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_exti.c
            BSP/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_flash_ex.c
            BSP/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_pwr.c
            PROPERTIES
            COMPILE_FLAGS -Wno-unused-parameter)

The project builds again with no warning! Great!

Conclusion

It is always a good idea to configure the compiler with many options to be warned about suspicious code. In C and C++, warnings are often potential bugs / not portable constructs / performance issues / etc. We should rely on the compiler to tell us about such code.

If adding options raise warnings in files that we don't own and can't modify, we can use CMake's set_source_files_properties() function to apply specific options to these files to suppress the warnings.

Comments

[Dan Collins]

I figure you can probably add these files to a variable, allowing you to pass it to both the list of sources and this warning suppression? That way you only update your list of ST sources in one place :)

[Pierre Gradot]

Hi!

I guess you can.

In this particular case, I was trying to be as simple as possible ;)

In general, I am not super fond of variables for list of files. Indeed, when a file is not found, CMake will raise the error where the variable is used, not where it is set. When you have multiple files in your build, it is sometimes painful to find the root of the issue. Hence, I use them when they really improve the code.

Also note that here I am selectively applying the options to some of ST's files, not all of them. If you use one variable with all ST's files, you will probably use more aggressive options, such as -w to silent all warnings.

[Dan Collins]

That's a good point, yeah. Explicit error suppression is nice in that way :)

Thanks again for a great series - I'm planning on having a play this evening.

[Pierre Gradot]

And eventually, did you play? :)

[Dan Collins]

I did! I've got a blinky light running on the F7 discovery board. I'll be figuring out how to add features like generating a 'version.h' with git info, and perhaps having a per-file logging level. I used to use SCons for this, but I like how well supported / deployed CMake is.

[Pierre Gradot]

I have generated such version.hpp files, but for SVN. I used stackoverflow.com/questions/378066...

For Git, there is cmake.org/cmake/help/latest/module... but there are less commands than with SVN. You will probably find tips on Stackoverflow ;)