2017-05-29 11:55 PM
Hi guys,
CubeMX supports makefile generation starting from 4.21.0 version. I've tested the makefile, however, there are some issues:
Major issues:
- missing header files dependency (make won't update the output in case a header file is updated)
Minor issues:
- the arm-none-eabi-xxx path is by default /arm-none-eabi-xxx destination (instead of arm-none-eabi-xxx, so the user has to define the path while calling make)
There might be other issues, however I haven't stumbled on them for now. I've opened this discussion to help update the makefile for future CubeMX release which would fit all!
For those who are interested as I was already working on my own makefile, I would like to share it. It inherits some ideas from here & there and includes dependency generation (described here:
http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/
).Makefile template description:
- the makefile has to reside in the root of your project folder
- c-files, h-files, asm-files and linker script file are searched automatically (no need to update the makefile once you add new sources under the project folder)
- the system builds *.o files out of the found files into folder defined by OBJDIR macro
- the system builds *.d (dependency) files as a side effect of the compilation and puts them into folder defined by DEPDIR macro
- the system builds $(TARGET).elf, $(TARGET).hex & $(TARGET).bin into OBJDIR folder
As I'm not an expert on all the GCC tools, there might be bugs in my makefile (missing compiler option/macro etc. wrong approach). So feel free to comment on my makefile so we can tune it up for future use and support ST in their work!
Thank you very much and have a nice day,
ST Renegade
#cubemx #makefile2017-05-30 01:18 AM
Hi
Musil.Vojtech
,Thank you for your feedback.I will forward this to our MX team for check.
-Nesrine-
2017-07-05 04:34 PM
I found some other issues with the generated Makefile. I am making a project for the STM32F030 using the LL drivers.
After generation the Makefile defines a variable called `SOURCES_DIR` that's not used anywhere else in the Makefile:
SOURCES_DIR = \
Application/MAKEFILE \Drivers/STM32F0xx_HAL_Driver \Application/User \Drivers \Application \Drivers/CMSISHalf of these directories don't even exist, but that doesn't really matter since `SOURCES_DIR` is not referenced anywhere else in the Makefile.
There's another couple of empty variables generated, PERIFLIB_PATH =, and PERIFLIB_SOURCES =, which are also not used anywhere else.
2017-08-03 12:34 AM
Hi ST,
The CubeMX is one version older (4.0 now) and still the Makefile is wrong. :\
At the moment I've three points:
1) user has to define a path to the toolchain (compiler, asssembler etc.) by defining a BINPATH variable as an input argument to make. If not, make complies that /arm-none-eabi-gcc does not exist. Either remove the BINPATH completely, or make it so, that in case it's empty the CC will become arm-none-eabi-$(PREFIX) instead of /arm-none-eabi-...
2) The header dependencies are still not working, even I reported it in my original post. :(
I saw some parts related to dependencies generation are included, however the object code etc. does not rely on it. Simple test:
make BINPATH=/usr/bin all
touch Inc/main.h
make BINPATH=/usr/bin all
make: Nothing to be done for 'all'.
A question arises. Are the devs testing their code? Seriously now? I'm sorry being rude, but the error has been reported and a fix which has been implemented is still not working. So I'm wondering how the team is integrating and testing the changes!
3) While I made a quick test of the new version, I get an error like cannot create build directory. I think this relates to the line:
$(BUILD_DIR):
mkdir $@
Include a '-p' flag to make sure this command won't fail even when the directory exists...
Have a nice day,
Renegade
________________ Attachments : Makefile.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyX5&d=%2Fa%2F0X0000000b99%2FVcXWtEahiy71Du.O4CvPtP.uqNdxtNTQBGAVDnVlskA&asPdf=false2017-09-06 03:35 AM
Hi ST Renegade,
Thanks for having reported the issue.The correction is planned in next CubeMx v4.23.0.Regards.Cyril2017-10-28 02:19 PM
Hi ST,
This dependency issue does not appear to be fixed in CubeMx v4.23.0. Additionally, the generated Makefile appears to have more problems with SOURCES_DIR. For example:
SOURCES_DIR = \
Application/MAKEFILE \
Middlewares \
Application/User/Src/gpio.c \
Application/User/Src/stm32f7xx_it.c \
Application/User/Src/stm32f7xx_hal_timebase_TIM.c \
Drivers/STM32F7xx_HAL_Driver \
Application/User \
Application/User/Src/stm32f7xx_hal_msp.c \
Application \
Application/User/Src/main.c \
Drivers \
Drivers/CMSIS \
Application/User/Src/freertos.c \
Middlewares/FreeRTOS \
Application/User/Src \
Application/User/Src/usart.c
Application directory is not created by CubeMx and files (e.g. gpio.c) should not be referenced in SOURCES_DIR.
Regards,
...doug2017-10-28 04:47 PM
Hi All,
Studying the CubeMx generated Makefile, two tweaks are needed to get it to generate/use dependencies properly.
1. Change CFLAGS from
CFLAGS += -MMD -MP -MF'$(@:%.o=%.d)' -MT'$(@:%.o=%.d)'
to
CFLAGS += -MMD -MP -MF'$(@:%.o=%.d)'
The -MT option is changing the dependency rule target from *.o to *.d. This is not what we want. We want the dependency rule target to be *.o so make will append the desired dependency rule prerequisites to the *.o rule being evaluated. make knows to do this since the dependency rule does not contain a recipe.
2. Add the following to the end of the Makefile
-include $(OBJECTS:.o=.d)
This pulls all the dependency files into the make. -include is used since no dependency files will exist for a clean build; without it, a clean build would fail.
Hope this helps,
...doug
2018-04-03 03:31 AM
Hello
Musil.Vojtech
,This issue has been addressed for the next cube release.
No excuse for this delay.
Kind regards
Sirma
2018-06-01 04:39 AM
Hello
Musil.Vojtech
,This issue is fixed in next CubeMX( 4.0) planned for next week.
Regards,
Houda