I have a CMake project for cross compiling executables for the STM32. The project structure includes folders for the various dependencies required, where the sources and header files are included in those folders. The CMakeLists.txt file to build the project is as easy as setting up for cross compilation and then globing together the sources from each dependency and user code, followed by setting the locations of all the headers with include_directories. Finally, add_executable is used to combine everything and build the binary.
I realize, this is probably not the most optimal way to do this (should probably build the deps as libraries), but it does work for now.
The issue comes in with a dep that has many layers of subdirs (lwIP), and the source and header files contain include statements that are references to levels of subdirs in that dep. For example, the lwIP file structure looks like:
> LwIP
| include
| lwip
| err.h
| netif
An lwIP source file (or header file!) might include "lwip/err.h". Of course, the preproc cannot find this file because the relative path makes no sense to it.
How should I configure this project such that these includes can be used without modifying source or header files?
The usual way to get around this issue is to create your own find module i.e. FindXXX.cmake (in your case it is FindLwIP.cmake) so that you can create LwIP_INCLUDE_DIRS variable within the package.
set(LwIP_INCLUDE_DIRS
${CMAKE_CURRENT_LIST_DIR}/../LwIP/include
${CMAKE_CURRENT_LIST_DIR}/../LwIP
${CMAKE_CURRENT_LIST_DIR}/../LwIP/include/XXX)
.
.
(omitted..)
.
.
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(LwIP DEFAULT_MSG LwIP_INCLUDE_DIRS LwIP_SOURCES LwIP_HEADERS)
With the above find module, your application can cleanly include the package and use the variables that are created by the find the module.
find_package(LwIP REQUIRED)
.
.
(omitted...)
.
.
include_directories(LwIP_INCLUDE_DIRS)
add_executable(${PROJECT_NAME}.elf ${SOURCES})
Since your work is related to STM32 & cmake, let me give you a great reference which will be a nice starting point for your work as well.
https://github.com/ObKo/stm32-cmake.git
Hope this helps.
Related
I have project which has not been divided into libraries, but the source is organized in a directory tree. I do not know how to tell cmake to go down a directory, then add the source in that directory to project defined in the parent directory. I have attempted the following:
in project/source/CMakelists.txt:
set(SOURCE
${CMAKE_CURRENT_SOURCE_DIR}/unitTest/main.cpp
)
add_subdirectory("${PROJECT_SOURCE_DIR}/folder1")
add_executable(UnitTestRNG ${SOURCE} ${HEADERS})
then in project/source/folder1/CMakeLists.txt:
set(SOURCE
${SOURCE}
${CMAKE_CURRENT_SOURCE_DIR}/file1.cpp
${CMAKE_CURRENT_SOURCE_DIR}/file2.cpp
)
set(HEADERS
${HEADERS}
${CMAKE_CURRENT_SOURCE_DIR}/file1.hpp
${CMAKE_CURRENT_SOURCE_DIR}/file2.hpp
)
using some message() statements, I have found that the the child folder will get the contents of the SOURCE variable, but it's new assignment to that variable will not persist on returning to the parent CMakeLists.txt
Looking for examples and at the cmake tutorial has led me to the conclusion that:
- Source file structures are usually flat within a project
- If code is divided into folders, it is usually is divided into corresponding libraries.
I wonder if there is some "best practice" from which I am deviating by attempting this structure.
Since CMake 3.1 there is a new way to add source from subdirectories: target_sources
Say you have root_dir and root_dir/sub_dir and source files in both. With target_sources you can do this:
In root_dir/CMakeLists.txt define the target
add_library(some_target main.cpp)
add_subdirectory(sub_dir)
In root_dir/sub_dir/CMakeLists.txt add sources:
target_sources(some_target PRIVATE more_cool_stuff.cpp)
some_target will now contain both source files.
It is also possible to use other commands in root_dir/sub_dir/CMakeLists.txt using some_target, for example target_compile_definitions which is quite convenient to add compilation definitions.
I learned about target_sources here, check it out if you want more explanation and examples
Like the second part of arrowdodger's answer says:
in project/source/folder1/CMakeLists.txt:
set(SOURCE
${SOURCE}
${CMAKE_CURRENT_SOURCE_DIR}/file1.cpp
${CMAKE_CURRENT_SOURCE_DIR}/file2.cpp
PARENT_SCOPE
)
set(HEADERS
${HEADERS}
${CMAKE_CURRENT_SOURCE_DIR}/file1.hpp
${CMAKE_CURRENT_SOURCE_DIR}/file2.hpp
PARENT_SCOPE
)
Can't you just set all your sources in project/source/CMakelists.txt then?
Anyway, what you need is PARENT_SCOPE or CACHE option on set command.
I am trying to implement the use of DSP in the STM32 F411RE board, but I cannot seem to include the necessary files without invoking numerous errors.
Background
I have previously had CMSIS and CMSIS-DSP working in Keil uVision, but given the code limit of 32k that puts me over the evaluation limit rather quickly. As such I have been attempting to include CMSIS-DSP into Atollic TrueStudio but this seemingly is difficult to accomplish: there is limited documentation available on the CMSIS-DSP to begin with and even less so for implementation in Atollic TrueStudio.
Some related resources can be found in the
Atollic TrueStudio User Guide
as well as
StackOverflow topic #1
and
StackOverflow topic #2
. Most other related topics I could find just refer to the use of Keil uVision or the User Guide without much further help.
Atollic TrueStudio does incorporate a in-built package manager where the base CMSIS is available for download, but it does not provide this option for the CMSIS-DSP pack.
Attempted solution
I have attempted to manually download the corresponding CMSIS package (STM32Cube_FW_F4_V1.24.0) and place the corresponding DSP package into the project file structure. This then permits the use of the DSP functions such as
#include arm_math.h or arm_rfft_fast_instance_f32 S; which can also be invoked with the use of the autocomplete functionality and as such are thus recognized by the IDE.
However, this process also invokes many errors as the included functions fail to recognize their header dependencies (such as the #include arm_math.h). I find it confusing that the main.c is able to recognize the #include arm_math.h command yet the functions included are not, but I nevertheless try to fix this by adding the CMSIS DSP to the included directories (found at 'Build properties --> C/C++ Build --> Settings --> Tool Settings --> C Compiler --> Directories`). However, this does also not remedy the issue at hand.
Code results
The function cannot find the header
However the main can find the exact same header
And the header is included in the build options -> directories
Just verified that it is also included in the 'path and symbols', which it should do automagically AFAIK once you include it in the build options:
Update
Since my OP I have made some progress, mostly via messing around with the includes, symbols and linker. I have now managed to defeat the original error (though unfortunately I have no idea how), but I have now incurred a large amount of additional errors for the startup_stm32 files.
These all appear to be bad instruction errors referring to the template files included in CMSIS (CMSIS / Device / ST / STM32F4xx / Source / Templates / ARM / ...), which somehow cannot interpret the various commands listed in these templates.
Example errors: bad instruction __heap_base
I have since figured out the issue for my project: including the CMSIS folder as available from the Github repo means that a lot of templates are present throughout the entire folder structure. When attempting to build / compile whilst these templates are still present it causes a lot of issues with invalidated types and re-defining errors.
Most of these templates are in a logical location, but some are buried quite deep down and may thus be difficult to find. I will try to make a video soon describing the process of adding CMSIS (DSP) from the github repo to your project in TrueStudio.
In the meantime, the following steps should make CMSIS and CMSIS-DSP work in your STM32 TrueStudio ProjecT:
Ensure that all templates (folders) are removed from the CMSIS folder. This may require some searching and experimenting: the particularly noxious ones are hidden in
../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/Device/ST/STM32xxxx/Source/{Templates}
whilst there are also other sets at ../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/DSP/{Examples} and ../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/DSP/{Projects} that I had removed for my project to compile / build succesfully.
Include all the folders that are named include in the folders. AFAIK you cannot just include the main ../Drivers folder, as includes do not appear to also include the underlying structure and it also seems to include errors for my project. Best to just include the folders manually: you can so so by right-clicking on the intended folder to include, click the option near the bottom "Add/Remove include path" and tick both boxes for release and debug before pressing 'OK' to include this folder. Repeat for the other 'include' folders.
Fish up the RTE_Components.h file located at ../STM32Cube_FW_xx_Vx/STM32xxxx-Nucleo\Templates\MDK-ARM\RTE. There are also files with this name (RTE_Components.h) available in the NN (Neural Networks) CMSIS-pack folder, do not touch those. Copy this file to any location that you have previously included (placed mine in ../Drivers/CMSIS/Include), and open it up in your IDE of choice. Add the line #define CMSIS_device_header " DEVICE_NAME.h " before any of the other statements and replace device name with your STM32 board name. For example, my RTE_Components.h file looks like
/*
* Auto generated Run-Time-Environment Component Configuration File
* *** Do not modify ! ***
* Project: 'Project'
* Target: 'STM32F410Tx_Nucleo'
*/
#define CMSIS_device_header "stm32f4xx.h" // define own board header, eg stm32f4xx.h or stm32f7xx.h
#ifndef RTE_COMPONENTS_H
#define RTE_COMPONENTS_H
#endif /* RTE_COMPONENTS_H */
Make sure that the device name for the CMSIS_device_header corresponds to the header .h
file located in ../Drivers/CMSIS/Device/ST/DEVICE_NAME/Include/DEVICE_NAME.h
Add the required symbols (right-click your project, go to properties, C/C++ General, Paths and Symbols; then go to the #Symbols tab) to define the FPU and your Cortex Core type. For me I need to add __FPU_PRESENT (either with no value or value '1') and because I have the Cortex M4 chip on the STM32F411RE I add ARM_MATH_CM4. This means that my list of Symbols looks like:
__FPU_PRESENT
__packed with value __attribute__((__packed__))
__weak with value __attribute__((weak))
-ARM_MATH_CM4
STM32F411xE
USE_HAL_DRIVER though this depends if you want to use the HAL or not
Again make sure that the necessary includes are well defined, as not including only 1 directory can lead to a large amount of errors. These can be found by going to project properties (right-click your project, option at the bottom), going to the C/C++ Build, Settings, then the Tool Settings tab, C Compiler dropdown and to the Directories option.
For my project I have the following include path's inside the project properties:
../Inc (should be by default)
../Drivers/CMSIS/Device/ST/STM32F4xx/Include (should be by default)
../Drivers/STM32F4xx_HAL_Driver/Inc (should be by default)
../Drivers/STM32F4xx_HAL_Driver/Inc/Legacy (should be by default)
../Drivers/CMSIS/Include (should be by default)
"${workspace_loc:/${ProjName}/Drivers/Device/ST/STM32F4xx/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/Core/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/Core_A/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/DSP/Include}"
Hopefully this helps and works for you too!
Background
I have a large cmake project that makes use of dozens of subprojects: some from in-house code bases, and some third-party projects which also use CMake.
To ensure common compiler options, I setup a macro in CMake called CreateDevFlags which is run in only the in-house sub-projects own CMakeLists file as the first line of code to execute. This makes sure that I don't break the compiler flags, output directory overrides, etc, for third-party projects, and all of the code I wrote myself is built with identical options.
Additionally, each sub project has a simple block of code along the lines of the following to define the source files to be compiled:
file(GLOB subproject_1A_SRC
"src/*.c"
)
file(GLOB subproject_1A_INC
"inc/*.h"
)
file(GLOB subproject_2B_SRC
"src/*.c"
"extra_src/*.c"
)
file(GLOB subproject_2B_INC
"inc/*.h"
"extra_details_inc/*.h"
)
Goal
I would like to add a sanity-check custom rule/function to the "master" CMakeLists file at the project root which runs all of the code for in-house subprojects through a code sanitizer (checks newlines, enforces style rules, etc).
Question
Is there a trivial way to have all "special" (ie: in-house) subprojects append their own source files to a "master" list of source (.c) and header (.h) files (possibly via the macro I created)? I realize I could manually create this list in the master CMakeLists file, but then I'd be duplicating efforts, and code maintainers would have to modify code in two places with this in effect.
Thank you.
One possible implementation would be to have a list called FILE_TRACKER defined at top scope for your project. Then, you could do something like
# Create local list to append to
set(LOCAL_LIST ${FILE_TRACKER})
# Append all of your source files, from your local source
foreach(SRC_FILE ${subproject_1A_SRC})
list(APPEND LOCAL_LIST ${SRC_FILE})
endforeach()
# Append to the upper macro (note: was initially set with FILE_TRACKER)
set(FILE_TRACKER ${LOCAL_LIST} PARENT_SCOPE)
The developers would only have to add their source to the one list, and the macro at the top level will be updated with the files.
In the end. the following approach solved my problem:
set(DIR1_SRCS "file1.cpp" PARENT_SCOPE)
and then in ./CMakeLists.txt
set(SRCS ${DIR1_SRCS} ${DIR2_SRCS})
I suggest you don't examine header files. Instead use include dirs for the paths to the header files. If you do this you will automatically get the depends working without having to track them yourself.
Your sanitizer should be able to parse the actual code to find and read the included headers.
Lets say my folder structure is something like this ..
+-- Application
|
+-- MICRO_CONTROLLER_1
|
+-- MICRO_CONTROLLER_2
|
+-- MICRO_CONTROLLER_3
and i have a compile switch ( SELECT_MICRO) set to #define SELECT_MICRO == MICRO_CONTROLLER_1 , then my project should build application with driver files in MICRO_CONTROLLER_1 , similarly if #define SELECT_MICRO == MICRO_CONTROLLER_2 , then application should build application with driver files in MICRO_CONTROLLER_2
Please let me know if there template to achieve the above.
You can export that particular path of the folder you want to build and supply the path to the executable. You can get further info. in this thread.
How I could add dir to $PATH in Makefile?
Or simply maintain different Makefiles to make different builds and use make -f to run that particular makefile.
I hope this is what you finally want to perform.
Typically you would define your pre-processor definitions to tell the pre-processor to include only, for instance, MICRO_CONTROLLER_1 blocks of code and ignore everything else.
Something like the following should suffice:
#if defined(MICRO_CONTROLLER_1)
// Block of code that is only available to MICRO_CONTROLLER_1
#elif defined(MICRO_CONTROLLER_2)
// ...
// All other microcontrollers you are supporting would follow this structure.
#endif
Then you would need to define MICRO_CONTROLLER_1. If you're using an IDE for development, there is typically a project option for pre-processor directives. This is where you would define MICRO_CONTROLLER_1. You could then create different "configurations" - one for each of the microcontrollers you are targeting.
This can only work if the directories have only include files. #define is a preprocessor directive. If the directories have source files, you need to solve it at the build system layer, not the preprocessor layer.
Assuming it's just include files, you'd just #include SELECT_MICRO # "Interface.h"
I have a C project that has the following structure
Main/
Makefile.am
bin/
src/
Makefile.am
main.c
SomeLibrarySource/
SomeFuncs.c
SomeFuncs.h
The main.c contains the main function that uses functions defined in the SomeFuncs.{h/c} files.
I want to use autotools for this project. I read a couple of resources on autotools. But, I was only able to manage using autotools for a single level project where all source, object and other files reside in the same directory.
Then I got some links that talked about using autotools for deep projects like this one and then I got confused.
Right now I have two Makefile.am as follows
Makefile.am
SUBDIRS=src
src/Makefile.am
mainprgdir=../
mainprg_PROGRAMS=main
main_SOURCES=main.c
I am pretty sure that these files should not be as I have them now :P
How do I use autotools for the above project structure? (At least what should be there in those Makefile.am(s) and where should I place them.
EDIT:
One more thing! At the end I would like to have the object files created in the bin directory.
Thanks
mainprogdir=../ does not make a whole lot of sense (you don't know what it is relative to on installation). Probably intended:
# Main/Makefile.am
# .━━ target for `make install`
# |
# ↓ ↓━━ target for compilation
bin_PROGRAMS = bin/main
# ↓━━ based upon compilation target name
bin_main_SOURCES = src/main.c
There are two main approaches. If the functions in SomeLibrarySource are used only by main, then there's no need to build a separate library and you can simply specify the source files in src/Makefile.am
main_SOURCES = main.c SomeLibrarySource/SomeFuncs.c
However, if you actually want to use the functions in other code in your tree, you do not want to compile SomeFuncs.c multiple times but should use a convenience library.
# Assigning main_SOURCES is redundant
main_SOURCES = main.c
main_LDADD = SomeLibrarySource/libSomeFuncs.a
noinst_LIBRARIES = SomeLibrarySource/libSomeFuncs.a
AM_CPPFLAGS = -I$(srcdir)/SomeLibrarySource
(You'll need AC_PROG_RANLIB in configure.ac to use convenience libraries.)
If the source file is named SomeFuncs.c, automake will not need Makefile.am to specify SomeLibrarySource_libSomeFuncs_a_SOURCES, but if the name of the source code file does not match the name specified in noinst_LIBRARIES, SomeLibrarySource_libSomeFuncs_a_SOURCES should be set to the list of files used to build the library. Note that you do not need to specify main_SOURCES, since main.c is the default value if left unspecified (but it's not a bad idea to be explicit.) (In all of this, I am not comfortable use CamlCase names, but the system I'm using uses a case insensitive file system (biggest mistake apple ever made) and the examples I give here are working for me. YMMV)
You could of course do a recursive make, or build the library as a separate project and install it. (I like the final option. Libraries with useful features should exist on their own.)