2023-12-04 12:46 PM
Hi,
I have project for STM32F405 created manually. Project is using fixed GCC 4.92014q4.
After updating STM32CubeIDE to version 1.14.0 i got warnings shown below.
Compiler option "Cyclomatic Complexity" is disabled.
File "subdir.mk" contains this rule:
# Each subdirectory must supply rules for building sources it contributes
Src/%.o Src/%.su Src/%.cyclo: ../Src/%.c Src/subdir.mk
How to remove this warnings?
2023-12-05 02:29 AM
Hello @Jan Wustrau
First let me thank you for reporting this issue.
I raised this internally along to our development team for fix.
Internal ticket number: 167964 is created (PS: this is an internal tracking number and is not accessible or usable by customers)
Thank you,
Souhaib
2024-01-16 04:20 AM
Hello,
Is there any solution for this issue?
2024-01-16 12:55 PM
Hello Jan,
another post relates to this topic : https://community.st.com/t5/stm32cubeide-mcus/stm32cubeide-1-14-0-flto-build-warning/td-p/614249
This bug was introduced by release 4.4 of GNU Make. Unfortunately as of today this is the latest, so you will have to wait for the official fix !
If you can't wait you can stick to a previous version available for download here.
2024-01-17 12:23 AM
Hi @Jan Wustrau ,
I also had this warning popping up after upgrading to 1.14.1 from 1.13.0, despite having compiler option "Cyclomatic Complexity" disabled just like you.
In order to get rid of it I enabled the option "Cyclomatic Complexity", and it was enough. It is NOT the solution I wanted (the subdir.mk files should be regenerated correctly when checking or unchecking the option), but it removes the warning, without (in my case) any impact on the compilation time.
By the way, have you tried to manually remove
Src/%.cyclo
from subdir.mk ?
Have a nice day.
2024-01-17 12:17 PM
Hi,
subdir.mk files are recreacted at each build, so manual removing this rule is not working.
Of course i tried to enable cyclomatic complexity, but i'm using old version of toolchain (2014) and this option is not supported:
arm-none-eabi-gcc: error: unrecognized command line option '-fcyclomatic-complexity'
2024-07-22 06:02 AM
My understanding is that this is not a bug introduced by the the update to Make, but an existing bug in the Makefile that is now highlighted by the new new warning Make 4.4.
The Makefile rule specifies multiple targets (the .o file and the .cyclo file). However, when the cyclomatic complexity option is disabled, the recipe doesn't generate the .cyclo file. Make is correctly warning you that you ran a recipie that didn't generate the target file.
When CubeIDE generates the makefile, it shouldn't include the .cyclo target if cyclomatic complexity is disabled.
In a future release of Make, this warning will be converted to an error, and CubeIDE will be unable build projects where this option has been disabled if the way the Makefiles are generated is not fixed.
2024-11-16 02:12 AM
Hello,
I have the same issue with my STM32CubeIde project. In the past, I enabled the Cyclomatic Complexity option for this project. The subdir.mk file was updated with the following code:
# Each subdirectory must supply rules for building sources it contributes
Core/Src/%.o Core/Src/%.su Core/Src/%.cyclo: ../Core/Src/%.c Core/Src/subdir.mk
And this warning appears during the compilation:
pattern recipe did not update peer target 'Core/Src/main.cyclo'. subdir.mk /MyProject/Debug/Core/Src line 34 C/C++ Problem
Trying to comment the line in the subdir.mk file or simply delete it do not solve the issue.
I'm agree with the solution When CubeIDE generates the makefile, it shouldn't include the .cyclo target if cyclomatic complexity is disabled.
My STM32CubeIDE version:
Version: 1.16.1
Build: 22882_20240916_0822 (UTC)
Regards
Pierrick
2024-12-16 02:35 AM
Hello, I would like to ask You if there is any progress with this issue. Today I try new version of ARM GNU Toolchain v14.2 together with actual version of STM32CubeIDE (1.17.0) and I encountered the same problem, where automatically generated makefile recipes do not take into account (disabled) "Cyclomatic Complexity" compiler setting.
Thanks to this, MAKE already generates the above listed warning:
Thank You
Peter