Rationalized Structure of CMAKE

About#

🎉 Finally, under the pressure of Keil's green corpse, the company is preparing to transition to the GCC compiler. I believe that the integration of the GCC toolchain has no better solution than CMAKE (of course, the EIDE plugin is also good). After a long period of independent exploration, we have completely kicked Keil out. Eclipse still cannot be completely eliminated, after all, TI's MCU still requires CCS. When will VSCode be fully popularized?

Recently, I converted the original project into a complete CMAKE project and found some points in the project structure that can be optimized.

Tools#

There should be a download for portable VSCode on the blog file service page, with all the necessary tools integrated, green and no installation required.

There is a file named ==1_First Run.bat==, double-click to run it, and VSCode can be used directly. The main function of this script is to elevate to administrator mode and automatically add the paths of various toolchains to the environment variables.

File Service - Saturn Ring Base

Rationalization of VSCode Workspace#

In the settings section of the .code-workspace file, you can add the following part

    "settings": {
        "C_Cpp.formatting": "clangFormat",
        "cmake.configureEnvironment": {
            "PROGRAM_NAME": "H7_GCC_PIONEER"
        }
    },

Here, the formatter is specified as clangFormat, and the executable file of this formatter will be added to the environment variables when ==1_First Run.bat== is executed.

A CMAKE environment variable is specified here for the convenience of configuring the name of the generated programming file.

In the main CMakeLists, which is in the root directory, there was previously such content

set(CMAKE_PROJECT_NAME DebugBuild)

It is modified to the following part

if(DEFINED ENV{PROGRAM_NAME})
    set(CMAKE_PROJECT_NAME $ENV{PROGRAM_NAME})
else()
    message(WARNING "PROGRAM_NAME environment variable is not set. Using default project name.")
    set(CMAKE_PROJECT_NAME "DefaultProjectName")
endif()

This way, it will take the PROGRAM_NAME from the workspace .code-workspace file as the standard.
This operation is mainly to ensure that the developers of this project do not modify any CMAKE-related files as much as possible, and there will be other operations aimed at this in the future.

Main Build Branch#

For CMAKE_BUILD_TYPE, it will be passed in from the CMAKE plugin for actual builds. But in addition to this build type, I also hope to have some custom build types, which can be operated as follows.

Use custom property variables in the earlier part of the executable main build.

set(CMAKE_BUILD_BL "YES")
set(CMAKE_BUILD_BL "NO")

And in the toolchain specification file, we can operate like this (of course, other files are similar, and these property variables of the main build will propagate to subdirectories and sub-builds)

if(CMAKE_BUILD_BL MATCHES YES)
    set(CMAKE_C_LINK_FLAGS "${CMAKE_C_LINK_FLAGS} -T \"${CMAKE_SOURCE_DIR}/CPU/GNU/stm32H743XI_INCBL.ld\"")   # Add link script
endif()
if(CMAKE_BUILD_BL MATCHES NO)
    set(CMAKE_C_LINK_FLAGS "${CMAKE_C_LINK_FLAGS} -T \"${CMAKE_SOURCE_DIR}/CPU/GNU/stm32H743XI.ld\"")   # Add link script
endif()

This operation controls two different linker scripts, where the linker script for YES includes the bootload part, mainly used for factory programming; while NO does not include the bootload part, used for upgrades. This reduces some operations, which the EIDE plugin cannot do so conveniently, as it requires manual minor modifications to the script each time. Of course, to minimize the modification of any CMAKE-related files by developers, an environment variable can also be created as in the previous operation.

Post-Build Tasks Defined in Main Build#

At the very end of my main build, there are the following two lines

# Add compile flags for individual files
include("${CMAKE_CURRENT_LIST_DIR}/8_WorkSpace/CMake/toolCmake/extra-compile-flags.cmake")

# Run post-build tasks
include("${CMAKE_CURRENT_LIST_DIR}/8_WorkSpace/CMake/toolCmake/post-build-tasks.cmake")

extra-compile-flags.cmake#

The content of this file is as follows

include(${CMAKE_CURRENT_LIST_DIR}/cmake_func/functions.cmake)

set_compile_flags_for_matching_files(${CMAKE_PROJECT_NAME} "6_Rtos|7_Exlib" "-w")
set_compile_flags_for_matching_files(user_src "6_Rtos|7_Exlib" "-w")

The purpose is to add the -w compile flag to the main build project ${CMAKE_PROJECT_NAME} and the source files introduced in the project user_src regarding the source files under the 6_Rtos or 7_Exlib folders, meaning to ignore all warnings. Since we have enabled ultra-strict all warnings, there may be some warnings in the operating system or libraries written by others that are very annoying and cannot be modified, hence this operation. Note that since the source files introduced in the project user_src were originally defined with the INTERFACE property, the source files in user_src cannot be properly added with compile flags, so the target_sources part should now be defined with the PUBLIC property, and no unacceptable side effects have been found so far.

The first parameter is the project name, the second parameter is the path containing these fields of source files, and the third field is the expected compile flags to be added, which introduces a new file functions.cmake as follows.

# FUNC

# Function to recursively include header files
function(include_sub_directories_recursively root_dir)
    if (IS_DIRECTORY ${root_dir})               # Is the current path a directory? If so, add it to the include directories
        message("include dir: " ${root_dir})
        target_include_directories(${PROJECT_NAME} INTERFACE
        ${root_dir}
        )
    endif()

    file(GLOB ALL_SUB RELATIVE ${root_dir} ${root_dir}/*) # Get all files in the current directory, let them be in the ALL_SUB list
    foreach(sub ${ALL_SUB})
        if (IS_DIRECTORY ${root_dir}/${sub})
            include_sub_directories_recursively(${root_dir}/${sub}) # Recursively call for subdirectories
        endif()
    endforeach()
endfunction()

# Add expected compile flags to source files with keywords in their paths (e.g., "-w")
function(set_compile_flags_for_matching_files target_name keywords compile_flags)
    # Get the original source file list of the target
    get_target_property(src_list ${target_name} SOURCES)

    # Check if the target exists and has source files
    if(NOT src_list)
        message(WARNING "Target '${target_name}' does not exist or has no sources.")
        return()
    endif()

    # Create a new list to store the files that need to have compile flags set
    set(filtered_src_list)

    # Traverse the original source file list and filter out the needed files
    foreach(src_file IN LISTS src_list)
        if("${src_file}" MATCHES "${keywords}")
            list(APPEND filtered_src_list ${src_file})
        endif()
    endforeach()

    # Set compile flags for the filtered source files
    foreach(src_file IN LISTS filtered_src_list)
        set_source_files_properties(${src_file} PROPERTIES COMPILE_FLAGS "${compile_flags}")
    endforeach()
endfunction()


# FUNC END

This is a file I specifically use to write CMake functions, but I won't elaborate on it; anyway, it will be included when functions are needed.

post-build-tasks.cmake#

This file is for conveniently managing post-build tasks, and its content is as follows

# Manage post-build tasks separately

# Define toolchain tools
set(OBJCOPY arm-none-eabi-objcopy)
set(OBJDUMP arm-none-eabi-objdump)

# Add custom commands to generate bin and hex files
add_custom_command(TARGET ${CMAKE_PROJECT_NAME} POST_BUILD
    COMMAND ${OBJCOPY} -O binary $<TARGET_FILE:${CMAKE_PROJECT_NAME}> ${CMAKE_PROJECT_NAME}.bin
    COMMAND ${OBJCOPY} -O ihex $<TARGET_FILE:${CMAKE_PROJECT_NAME}> ${CMAKE_PROJECT_NAME}.hex
    COMMAND  ${CMAKE_CURRENT_LIST_DIR}/gccMapView.exe ${CMAKE_BINARY_DIR}
    COMMENT "Generating bin and hex files from elf"
)

This is to generate bin and hex files.
Then I ran gccMapView.exe, which is a small software I created to organize maps, because the original GCC map is simply ugly, so I have this small software. The open-source address is here, and the effect is quite good.

stbanana/gcc-elf-link-sort: A tool for sorting the symbols of .elf by address

Original map.png

Organized output.png

Automated Traversal Search for Project Source Code Inclusion#

The project source code traverses header file paths and includes them, with such parts

# cmake FUNC
include(${CMAKE_CURRENT_LIST_DIR}/cmake_func/functions.cmake)

# Recursively include header files
include_sub_directories_recursively(${CMAKE_CURRENT_LIST_DIR}/../../../1_App)
include_sub_directories_recursively(${CMAKE_CURRENT_LIST_DIR}/../../../2_Contorl)
include_sub_directories_recursively(${CMAKE_CURRENT_LIST_DIR}/../../../3_Module)
include_sub_directories_recursively(${CMAKE_CURRENT_LIST_DIR}/../../../4_Driver)

This will call the CMake functions, so it is also in the unified function definition file, and its purpose is to add all paths including subdirectories under these four folders to the include path.

There is also such a part

# Recursively find all source files
file(GLOB_RECURSE 1_APP_SRC ${CMAKE_CURRENT_LIST_DIR}/../../../1_App/*.c)
file(GLOB_RECURSE 2_CONTORL_SRC ${CMAKE_CURRENT_LIST_DIR}/../../../2_Contorl/*.c)
file(GLOB_RECURSE 3_MODULE_SRC ${CMAKE_CURRENT_LIST_DIR}/../../../3_Module/*.c)
file(GLOB_RECURSE 4_DRIVER_SRC ${CMAKE_CURRENT_LIST_DIR}/../../../4_Driver/*.c)
file(GLOB_RECURSE 5_DRIVER_SRC ${CMAKE_CURRENT_LIST_DIR}/../../../5_PhysicalChip/Stm32H7/*.c)

target_sources(${CMAKE_PROJECT_NAME} PUBLIC
    ../../../main.c
    ${1_APP_SRC}
    ${2_CONTORL_SRC}
    ${3_MODULE_SRC}
    ${4_DRIVER_SRC}
    ${5_DRIVER_SRC}
)

The purpose is to add all source files including subdirectories under these four folders to the source files.

As for the lower-level parts and RTOS or introduced libraries, the inclusion of source code and include paths is still manually specified.

After doing this, all the garbage business source code can be freely written and modified. Previously, changing a name or structure required modifying many project configurations everywhere; now, business code can be developed smoothly. The business code and driver support are further decoupled.

Here is a modification mentioned earlier; the target_sources part should now be defined with the PUBLIC property; otherwise, it is impossible to specify compile flags for individual files. Although the INTERFACE property will be processed during actual compilation and will be linked in the main build project, in the CMAKE system, there is no file instance for this, essentially it is virtually linked in the source introduction project user_src, but user_src is also an INTERFACE virtual library that will not actually compile, so all source codes are linked into the main build project as a whole, and no accurate file can be found, only inheriting the compile flags of the main build project to participate in the compilation.

This article is synchronized and updated to xLog by Mix Space. The original link is https://www.yono233.cn/posts/novel/24_11_25_CMAKE%E7%9A%84%E5%90%88%E7%90%86%E5%8C%96%E7%BB%93%E6%9E%84