嵌入式系统编程【免费下载链接】fprimeF´ - A flight software and embedded systems framework项目地址https://gitcode.com/gh_mirrors/fp/fprime点击查看免费下载导读F´F Prime是一个面向飞行软件与嵌入式系统的开源框架。本文以仓库内 CMake 构建系统软件设计文档 为主体系统讲解 F´ 基于 CMake 的全新构建系统它为何取代继承自 JPL 火星科学实验室MSL任务、已存在十余年的旧构建系统具备哪些明确的构建需求以及把 F´ 当作库的三种操作范式如何落地。结合仓库中 cmake/FPrime.cmake、cmake/API.cmake、cmake/module.cmake 等源码你将掌握 F´ 模块/可执行程序/单元测试的注册机制、CMake 文件组织方式以及如何为 F´ 添加新组件、新拓扑与新平台。1 背景与目标为什么 F´ 需要一套新构建系统F´ 的旧构建系统继承自 JPL 火星科学实验室MSL任务创建于十多年前。随着 F´ 的演进旧系统难以增强和维护的问题日益突出因此 F´ 引入了基于流行开源工具 CMake 的新构建系统。本文档Software Design DocumentSDD给出了该构建系统的一组需求、若干操作概念以及候选的构建系统设计。新构建系统要解决的核心痛点包括模块构建顺序旧系统要求显式指定全部模块的顺序而 F´ 模块众多显式排序十分困难配置隔离旧系统存在全局 make 配置目录的问题不同部署无法独立配置依赖扩展成本旧构建系统学习曲线陡峭新增组件成本高构建形态单一F´ 不仅有部署deployment还有可执行工具、库、单元测试等多种产物。1.1 术语定义SDD 中以下术语具有特定含义是理解后文的基础术语含义Host用于构建代码的机器或架构Target代码为之构建的机器或架构Build Commands通过 make 系统运行的命令In-Source Build在源码旁生成构建产物Out-Of-Source Build在独立于源码的目录中生成构建产物Build Configurations不同的构建设置如不同目标、调试标志、不同部署通常彼此隔离F´ ModuleF´ 组件与 F´ 端口的超集Deployments包含框架、旨在以 F´ 形式运行的 F´ 二进制/可执行文件Executable由构建系统构建的二进制不旨在作为 F´ 部署运行2 构建需求清单RequirementsSDD 以需求表的形式定义了新构建系统必须满足的能力每项都标注了验证方法与当前状态是判断该系统设计完成度的重要依据。完整清单如下需求描述理由验证方法状态BUILD-01构建系统应支持在 Linux 和 Mac OS 上进行原生 F´ 构建和安装JPL 的 F´ 开发在 Linux 和 Mac OS 上进行InspectionDoneBUILD-02构建系统应提供支持其他 Host 操作系统的模板模板使添加主机更容易InspectionDoneBUILD-03构建系统应提供支持其他 Target 的模板模板使添加新目标更容易InspectionDoneBUILD-05构建系统应提供交叉编译目标示例交叉编译在 JPL 很常见必须提供示例InspectionDoneBUILD-06构建系统应支持自定义构建命令自定义构建命令允许扩展构建系统InspectionDoneBUILD-07构建系统应支持单个组件、端口和拓扑的构建编译特定组件可加速开发Unit TestDoneBUILD-08构建系统应支持单元测试构建和运行系统检查单元测试对正确开发至关重要Unit TestDoneBUILD-09构建系统应支持构建部署部署必须正确构建Unit TestDoneBUILD-10构建系统应支持与其他构建系统集成有些库自带其他 make 系统Included within CMakeDoneBUILD-11构建系统不应要求所有模块按特定顺序构建当必须显式指定时排序所有 F´ 很困难InspectionDoneBUILD-12构建系统应支持 F´ 的独立 out-of-source 构建构建产物通常与源码分开保存InspectionDoneBUILD-13构建系统应支持可执行文件和工具构建并非所有 F´ 都是部署InspectionDoneBUILD-14构建系统应支持输出、头文件和库的安装与分发二进制输出的交付对项目很重要InspectionNeededBUILD-15构建系统应支持用户可配置的构建如 debug、release 等F´ 可能需要不同构建变体用于调试InspectionWork-AroundBUILD-16构建系统应易于使用包括添加新组件F´ 现有构建系统学习曲线陡峭InspectionDoneBUILD-17构建系统不应明显缓慢编译时间不可忽视InspectionDoneBUILD_18部署应独立配置依赖当前 F´ 存在全局 make 配置目录问题InspectionDoneBUILD_19构建系统不应难以设置和配置将现有 F´ 部署移植到新 make 系统不应需要大量工作InspectionDoneBUILD_20构建系统应支持将 F´ 作为库、子仓库和子目录使用即使 F 是只读的未来 F´ 使用应将核心视为输入InspectionDoneBUILD_21构建系统应支持 Windows 主机未来希望支持 Windows 构建InspectionNeededBUILD_22构建系统应支持构建子拓扑子拓扑是未来期望InspectionRemoved注需要 Autocoder 功能支持BUILD_23构建系统应支持将 F´ 核心构建为一组共享库未来某些任务可能受益于共享 F´ 核心InspectionDoneBUILD_24构建系统应支持 UT 和验证阶段钩子验证和对单元测试支持的增强有益于更好的项目开发InspectionNeededBUILD_26构建系统应支持执行单个、一组或所有基于 gtest 的单元测试DoneBUILD_27构建系统应支持 F´ Autocoder 的显式和隐式执行DoneBUILD_28构建系统应验证所需的编译器、链接器、库等已安装在执行构建的主机上DONEBUILD_29构建系统应实现旧 F´ 构建系统的所有用户目标Deferred需要单独的构建命令BUILD_30构建系统应支持执行单个、一组或所有基于 GSE 的集成测试注这是 GDS/GSE 流程而非构建流程。使用 fprime-gds 很容易实现BUILD_31构建系统应支持执行单个、一组或所有 F´ Autocoder 及关联工具测试Done从表中可以看到绝大多数核心需求已完成Done仅 BUILD-14安装/分发、BUILD-15构建变体目前为变通方案、BUILD-21Windows、BUILD-24UT/验证阶段钩子、BUILD-29旧系统全部用户目标已推迟等仍处于未完成或待定状态这为后续迭代指明了方向。3 操作范式Operations Concepts三种使用 F´ 的方式CMake 可以三种方式运行代表使用 F´ 的不同范式。核心区别在于构建产物对象、库、归档、makefile有时还有自动生成代码放在哪里Out-of-Source 构建产物放在与源码分离的目录中In-Source 构建产物与源码放在一起。现代构建系统强烈不鼓励甚至禁止 in-source 构建因为内容管理、构建配置、版本控制和开发都会因此变得更困难。CMake 系统允许 in-source 构建但仅当精确地按旧 make 系统的运行方式操作时才可行。因此共有三种操作范式推荐将 F´ 视为库执行 out-of-source 构建将项目代码直接加入 F´仍执行 out-of-source 构建强烈不鼓励将代码加入 F´进行 in-source 构建。注意与旧 make 系统并存时这无法工作。不同的构建配置不同目标、不同 cmake 选项、不同部署、debug 构建等通常放在不同的构建目录中如build_raspi_debug使所有配置与输出完全隔离——既不会产生链接混淆或构建冲突也不会因状态被遗忘而构建出错误的东西。范式 1 和 2 天然支持这种隔离而范式 3in-source则必须在切换时清除一切构建产物因此被强烈不鼓励。3.1推荐将 F´ 作为库使用 Out-Of-Source 构建在该设计中F´ 作为项目的一个子目录被包含。所有适配代码都放在 F´ 目录之外从而可以顺畅地更新、打补丁、冻结 F´ 核心组件并可轻易扩展为将 F´ 作为库链接。构建在用户指定的目录中进行用户创建命名的构建目录然后向 cmake 提供配置参数完成构建设置。适配代码与核心顶层目录并排存在每种配置对应一个独立构建目录。每种构建类型只需设置一次之后可以反复执行 makecd project mkdir build_config1 cd build_config1 cmake ../path-to-deployment -Dconfiguration settings当代码或 make 文件发生变化时开发迭代期间可随时重跑cd project/build_config1 make单个组件的构建方法见下文3.3 out-of-source 构建单个组件。3.2 传统 F´ 组织方式 Out-Of-Source 构建在该设计中F´ 核心与适配代码都放在 F´ 目录中这是使用 F´ 的传统方式。它不那么容易把 F´ 作为库使用且更新 F´ 时略显困难但除此之外是一种稳定可靠的方法。使用方式与 3.1 几乎相同唯一区别是所有代码都在 F´ checkout 内这要求完整 fork F´。cd fprime mkdir build_config1 cd build_config1 cmake ../path-to-deployment -Dconfiguration settingscd project/build_config1 make3.3 Out-Of-Source 构建单个组件在 out-of-source 构建中构建 F´ 内的单个组件时需要切换到并行的构建结构中以找到组件的构建目录F´ 核心组件位于build/F-Prime/path-to-component适配组件通常位于build/adaptation/path-to-component然后在该目录中执行 make 即可构建该组件。单独构建 F´ Svc 组件cd build_config1/F-Prime/Svc/FatalHandler make单独构建 Ref 组件cd build_config1/Ref/PingReceiver/ make这种能力对应需求 BUILD-07支持单个组件、端口和拓扑构建——编译特定组件可显著加速开发迭代。3.4强烈不鼓励旧式 In-Source 构建该范式仅为不破坏旧 F´ 工作流而保留带有若干警告它不能与旧 make 系统并行运行会覆盖旧 make 系统的产物重新配置构建设置必须删除所有构建与 CMake 产物切换构建配置时可能出现链接和构建错误。cd fprime git clean -xdf . # 警告这会清除*所有*未跟踪文件 cmake ../path-to-deployment -Dconfiguration settings make每次运行构建时必须执行以上命令以防错误和不可预测的构建。然而清除构建系统的全部产物过于粗暴——配置会丢失或污染新构建这正是本范式被强烈劝阻的原因。若确实需要采用务必理解上述警告并具备应对负面后果的安全机制。3.5 添加新组件与拓扑新组件可通过在组件目录中创建CMakeLists.txt文件来添加。该文件必须设置两个 CMake 变量SOURCE_FILES作为源码或自动编码autocoding源文件的文件列表MOD_DEPS可选模块和链接依赖列表。使用 CMake 的set()函数设置最后调用 F´ 的 CMake 支持函数register_fprime_module它负责设置自动编码步骤并确保该组件作为 F´ 模块构建。模块 CMakeLists.txt 示例# Default module cmake file # SOURCE_FILES: Handcoded C source files set(SOURCE_FILES ${CMAKE_CURRENT_LIST_DIR}/PingReceiverComponentAi.xml ${CMAKE_CURRENT_LIST_DIR}/PingReceiverComponentImpl.cpp ) # Note: no MOD_DEPS needed. register_fprime_module()仓库中 Ref/PingReceiver/CMakeLists.txt 就是这一模式的现代版本它把.fpp自动编码输入与手写实现.cpp一并列入SOURCE_FILES由于依赖可由自动编码输入自动推断因此无需MOD_DEPS即可直接调用register_fprime_module()。该文件必须通过add_subdirectory加入某个父级CMakeLists.txt。若是新 F´ 组件通常加入该组件所在顶层目录的CMakeLists.txt如fprime/Svc/CMakeLists.txt这些子级 CMakeLists.txt 是便捷性的存在由 FPrime.cmake 自身包含。若没有方便的列表文件组件可直接加入fprime/cmake/FPrime.cmake非核心组件则必须加入部署的CMakeLists.txt或从其包含的子文件加入。示例添加子目录add_fprime_subdirectory(${CMAKE_CURRENT_LIST_DIR}/PingReceiver/)拓扑CMakeLists.txt与模块文件格式相同但有两点偏差首先MOD_DEPS通常需要定义因为某些依赖无法自动检测、必须显式选择其次调用的是register_fprime_executable因为将生成可执行文件。拓扑 CMakeLists.txt 示例# Default deployment cmake file # SOURCE_FILES: Handcoded C source files # MOD_DEPS: Modules needed by this deployment set(SOURCE_FILES ${CMAKE_CURRENT_LIST_DIR}/RefTopologyAppAi.xml ${CMAKE_CURRENT_LIST_DIR}/Topology.cpp ) set(MOD_DEPS Svc/PosixTime Svc/PassiveConsoleTextLogger ) register_fprime_executable()仓库中的真实例子见 Ref/Top/CMakeLists.txt它把instances.fpp、topology.fpp、RefPackets.xml作为自动编码输入把RefTopology.cpp作为手写源码并显式声明了Fw/Logger、Svc/PosixTime以及Drv/Udp、Drv/TcpClient、Drv/TcpServer等通信实现依赖。这些文件同样必须加入入口CMakeLists.txt或其子文件。4 CMake 构建组织Build OrganizationCMake 系统由三部分组成入口文件由部署或可执行程序提供图中黄色来自部署/可执行程序通常由 F´ 适配项目提供F´ 核心 CMake 支持文件图中绿色提供构建组件、部署、模块的核心 CMake 函数CMakeLists.txt 文件图中蓝色/橙色用于构建核心与适配的 F´ 组件和拓扑。4.1 部署与可执行程序的 CMake 文件这些文件由被构建的部署或可执行程序提供承担两项关键职能职能一提供构建系统的入口。包含标准 CMake 头部和 F´ CMake 支持文件FPrime.cmake的包含语句还应包含FPrime-Code.cmake以纳入 F´ 核心代码确保 CMake 就绪且所有 F´ 设置已包含。典型的入口文件如下CMake 头部与 F´ 构建系统## # Section 1: Basic Project Setup # # This contains the basic project information. Specifically, a cmake version and # project definition. ## cmake_minimum_required(VERSION 3.16) project(FPrime-Ref C CXX) ## # Section 2: F´ Core # # This includes all of the F´ core components, and imports the make-system. F´ core # components will be placed in the F-Prime binary subdirectory to keep them from # colliding with deployment specific items. ## include(${CMAKE_CURRENT_LIST_DIR}/../cmake/FPrime.cmake) include(${CMAKE_CURRENT_LIST_DIR}/../cmake/FPrime-Code.cmake)仓库中 Ref/CMakeLists.txt 是这一结构的完整真实实现它在 Section 1 声明cmake_minimum_required(VERSION 3.16)与project(Ref VERSION 1.0.0 LANGUAGES C CXX)在 Section 2 先include上述两个核心文件其注释特别指出自定义 target 需在两个 include 之间注册并在 Section 3 通过add_fprime_subdirectory加入 PingReceiver、RecvBuffApp、SendBuffApp、SignalGen、TypeDemo 等组件目录与 Top 拓扑目录最后以register_fprime_deployment()注册部署MOD_DEPS为${PROJECT_NAME}/Top。职能二包含包含适配特定 F´ 组件的子目录。这与 F´ 核心子目录包含方式相同但代表适配特定组件## # Section 3: Components and Topology # # This section includes deployment specific directories. This allows use of non- # core components in the topology, which is also added here. ## # Add component subdirectories add_fprime_subdirectory(${CMAKE_CURRENT_LIST_DIR}/PingReceiver/) add_fprime_subdirectory(${CMAKE_CURRENT_LIST_DIR}/RecvBuffApp/) add_fprime_subdirectory(${CMAKE_CURRENT_LIST_DIR}/SendBuffApp/) add_fprime_subdirectory(${CMAKE_CURRENT_LIST_DIR}/SignalGen/)注意组件的输出被路由到构建中以Ref前缀开头的命名子目录。4.2 F´ 核心 CMake 支持文件这些文件提供构建组件、部署和模块所用的核心 CMake 函数。此外FPrime-Code.cmake包含组成 F´ 核心组件的子目录使部署只需包含这一个 CMake 文件即可导入整个 F´。自动化自动编码auto-code的函数、模块依赖处理及各种其他工具也都包含其中。因此部署和可执行程序在添加自定义组件时可遵循与 F´ 核心组件相同的模式。从源码看cmake/FPrime.cmake 是系统真正的入口它通过include_guard()保证只加载一次依次包含utilities、options、sanitizers、required加载平台设置然后包含module、autocoder/autocoder、target/target、API、sub-build/sub-build、settings等模块。其中的fprime_initialize_build_system宏完成了关键初始化设置全局 include 目录框架、配置、项目根与构建缓存、检测外部库、注册标准 targetbuild、FPP/XML/Packets 三类 autocoder、version、install、ut以及可选的 refresh_cache 与 check。fprime_setup_included_code则负责把 F´ 核心包Fw Svc Os Drv CFDP Utils与config目录、googletest、STest、Autocoders依次加入构建。4.3 F´ 核心与适配的 CMakeLists.txt 文件这些文件用于指定 F´ 组件、端口和拓扑的构建布局按层级组织见下图。它们调用 F´ 的模块与部署函数以生成预期构建文件格式已在 3.5 节描述链接源文件与自动编码器输入到生成函数由这些函数组装 F´。5 CMake 架构Architecture如前所述F´ 的大部分构建魔法封装在 CMake 工具函数中。架构中有两组主要函数每组都包含执行生成工作的原始函数generate_*和包装它们的 API 包装器register_*register_fprime_module/generate_module源码中为generate_library生成库/模块构建文件与依赖register_fprime_executable/generate_executable生成可执行程序构建与依赖。注意图中颜色继承自前述示意图红色为输出产物紫色代表执行步骤。5.1 模块函数register_fprime_module 与 generate_module模块函数旨在将 F´ 目录构造成一个库静态或共享。模块名由目录路径相对于仓库根目录的位置决定例如Fw/Comp变为Fw_Comp产物为libFw_Comp.a。该库作为 CMake 系统的输出添加由SOURCE_FILES构建——这些文件被拆分为自动编码器输入.xml、.txt、.fpp和普通源文件。特定依赖可通过MOD_DEPS提供但仅当依赖无法通过对自动编码文件中的全部.xmlinclude 做递归搜索而检测到时才需要。系统为每个自动编码输入文件注册自动编码生成步骤这些输入也用于检测模块的全部依赖普通源文件则提供给构建目录。这些步骤完成后CMake 生成主机特定的构建文件封装该模块的自动编码器调用、依赖与源文件。运行这些构建文件即生成模块库供部署链接阶段使用并注册到 CMake 以便参与全局依赖汇总。源码佐证cmake/module.cmakegenerate_library(MODULE_NAME SOURCE_FILES DEPENDENCIES)与generate_executable、generate_deployment、generate_ut都经由generate_base_module_properties落地该函数按目标类型Library/Executable/Deployment/Unit Test创建底层 target设置FP_TYPE属性并调用setup_module_targets完成源文件拆分、自动编码与依赖装配。5.2 可执行函数register_fprime_executable 与 generate_executable可执行函数旨在创建可执行程序。这些可执行程序拥有确定的源文件并自动把所有依赖汇总到一个全局有序的依赖列表。可执行程序名来自创建 CMake 项目时定义的${PROJECT_NAME}否则必须单独提供。可执行程序可提供SOURCE_FILES与MOD_DEPS可使用自动编码其余行为与上述模块类似唯一区别是构建输出为可执行程序。注意部署指定一个或多个可执行程序这些可执行程序成为依赖树的根。因此只生成所需的可执行程序、库与输出而不会显式构建整个 F´ 系统这使得构建更高效对应 BUILD-17。在 cmake/API.cmake 中register_fprime_executable与register_fprime_deployment均要求先定义SOURCE_FILES或MOD_DEPS可执行程序名优先取EXECUTABLE_NAME/传入参数否则回退到FPRIME_CURRENT_MODULE或PROJECT_NAME。register_fprime_deployment的 API 注释还特别说明部署几乎总是需要通过MOD_DEPS提供拓扑模块如${FPRIME_CURRENT_MODULE}/Top且不得把可执行目标放进MOD_DEPS会导致多重main定义等链接问题应改用 CMake 原生的add_dependencies建立纯 CMake 依赖。5.3 单元测试函数register_fprime_ut注册单元测试使用与上述相同的过程区别在于变量UT_SOURCE_FILES和UT_MOD_DEPS这允许同一文件既定义模块或可执行程序、又定义单元测试而不覆盖先前使用的变量。单元测试必须使用TESTING这一 cmake 构建类型构建以启用单元测试构建并设置make check目标。这既防止单元测试拖慢正常构建也允许为 UT 使用专门的编译标志。UT 注册到make check目标以支持一次性运行单个 UT 可按需从bin目录运行。建议从 F´ 顶层构建会拉入所有单元测试从部署构建则适合运行该部署的单元测试。UT 构建示例mkdir build_ut cd build_ut cmake .. -DBUILD_TESTINGON make -j32源码佐证register_fprime_ut在BUILD_TESTING未开启或__FPRIME_NO_UT_GEN__置位时直接返回UT 可执行文件默认命名为MODULE_NAME_ut_exe并支持UT_INCLUDE_GTEST、UT_AUTO_HELPERS等开关。真实用例见 Svc/ActiveLogger/CMakeLists.txt——它在注册模块之后用UT_SOURCE_FILES同时列出被测试的ActiveLogger.fpp模型与test/ut/下的两个 Tester 源文件随后调用register_fprime_ut()。5.4 添加新平台Adding New PlatformsCMake 允许在初始 CMake 步骤中指定工具链toolchain因此编译新的目标 OS 核心上只需cmake path to deployment -DCMAKE_TOOLCHAIN_FILEpath/to/toolchain_file然而仅这样添加工具链会忽略 F´ 为编译平台特定代码所做的一些便捷设置因此用户还必须注册一个平台文件。在fprime/cmake/platform/目录下创建platform.cmake文件即可定义新平台。工具链文件如需随 F´ 提供可加入fprime/cmake/toolchain/。源码佐证cmake/platform/platform.cmake平台解析的实际流程是——原生工具链使用系统名如 Linux、Darwin作为FPRIME_PLATFORM交叉工具链必须把CMAKE_SYSTEM_NAME设为Generic并设置FPRIME_PLATFORM否则直接报错。随后系统按项目根 → 库 → 框架的顺序查找cmake/platform/${FPRIME_PLATFORM}.cmake并加载找不到则给出明确的FATAL_ERROR。仓库当前内置了 Linux.cmake、Darwin.cmake、rtems5.cmake等平台文件并提供platform.cmake.template模板供新平台参考。5.5 常用构建选项让 CMake 配置更灵活SDD 主文中未展开、但实际构建中高频使用的选项集中在 cmake/options.cmake这里做补充说明。所有选项均通过-DOPTIONVALUE传入值通常为 ON/OFFfprime-util会自动设置其中一部分其余可通过fprime-util的-D透传选项默认值作用CMAKE_DEBUG_OUTPUTOFF输出 F´ CMake 集成的调试信息用于排查构建系统问题FPRIME_USE_STUBBED_DRIVERS平台决定ON 使用桩驱动serial/ipv4 驱动除外OFF 使用完整驱动实现FPRIME_USE_BAREMETAL_SCHEDULER平台决定ON 使用裸机单上下文调度器OFF 使用 OS 线程调度FPRIME_ENABLE_UTIL_TARGETSON启用check、refresh_cache等 fprime-util 目标FPRIME_ENABLE_FRAMEWORK_UTSON是否把 F´ 框架自身的 UT 加入目标列表FPRIME_ENABLE_AUTOCODER_UTSOFF是否同时启用 Autocoder 工具自身的 UTFPRIME_ENABLE_UT_COVERAGEON是否计算单元测试覆盖率FPRIME_ENABLE_TEXT_LOGGERSON是否构建 ActiveTextLogger/PassiveConsoleTextLogger 文本日志组件FPRIME_SKIP_TOOLS_VERSION_CHECKOFF跳过 F´ 工具版本检查高级选项ENABLE_SANITIZER_ADDRESS/LEAK/UNDEFINED_BEHAVIOR/THREADOFF为整个构建添加对应的 Sanitizer 编译/链接标志此外options.cmake还定义了四个关键路径变量——FPRIME_FRAMEWORK_PATHF´ 框架安装位置、FPRIME_PROJECT_ROOT项目根用于 C include 相对路径、FPRIME_LIBRARY_LOCATIONS分号分隔的外部库位置列表、FPRIME_CONFIG_DIR配置头文件目录——它们通常由fprime-util提供直接在 IDE 或裸 CMake 中构建时才需手工指定。另一个重要的构建行为是当CMAKE_BUILD_TYPE为TESTING时BUILD_TESTING自动开启这正对应 5.3 节UT 必须用 TESTING 构建类型的设计。5.6 真实模块中的条件编译与平台适配模块CMakeLists.txt不只是静态罗列源文件还可以根据构建选项/平台动态选择实现。例如 Svc/FatalHandler/CMakeLists.txt基础源文件为FatalHandler.fpp与FatalHandlerComponentCommonImpl.cpp随后依据FPRIME_USE_BAREMETAL_SCHEDULER、CMAKE_SYSTEM_NAMEVxWorks等条件追加 Baremetal、VxWorks 或 Linux 的实现文件最后声明Os与Fw/Logger两个MOD_DEPS并注册模块。这体现了 CMake 系统与 F´ 平台抽象Os/Models/Models.hpp 所定义的Os_Task、Os_FileSystem等接口协同工作的方式接口由框架定义实现由平台与部署按需选择。6 总结F´ 的 CMake 构建系统是一次围绕易扩展、易维护、配置隔离的彻底重构它以 31 条需求明确边界以三种操作范式覆盖库化使用/传统使用/旧式 in-source三种场景以register_*/generate_*两组函数完成模块、可执行程序、部署与单元测试的注册与生成并通过FPrime.cmake、FPrime-Code.cmake、options.cmake、platform.cmake等支持文件实现自动编码接入、依赖推断、平台适配与全局目标装配。对开发者而言新增组件只需一个设置SOURCE_FILES与MOD_DEPS、调用register_fprime_module()的CMakeLists.txt构建部署只需一次cmake配置加反复make单元测试则以BUILD_TESTINGON的 TESTING 构建类型与make check统一驱动。这套设计既是理解 F´ 现有工程实践的钥匙也为在 F´ 之上构建自己的飞行软件部署提供了完整、可复制的构建骨架。赞分享嵌入式系统编程【免费下载链接】fprimeF´ - A flight software and embedded systems framework项目地址https://gitcode.com/gh_mirrors/fp/fprime点击查看免费下载相关推荐F´ 飞控软件框架 CMake 构建系统设计与实践指南F´ 飞控软件框架 CMake 构建系统设计与实践指南 本指南以 F´F Prime开源仓库中的 CMake Build System 软件设计文档SDD嵌入式系统编程MoE模型压缩的未来REAP方法为何成为专家剪枝的黄金标准 MoE模型压缩的未来REAP方法为何成为专家剪枝的黄金标准 在人工智能模型飞速发展的今天 MoE模型压缩 技术正成为提升大模型效率的关键突破。本文将深CMake源码架构深度解析从模块化设计到构建系统的完整指南CMake源码架构深度解析从模块化设计到构建系统的完整指南 CMake作为当今最流行的跨平台构建系统工具其源码架构体现了现代软件工程的精髓。本文将从CMak构建工具开发工具CLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 F´ 的 CMake 构建系统软件设计解析：从需求、操作范式到源码级实现
嵌入式系统编程【免费下载链接】fprimeF´ - A flight software and embedded systems framework项目地址https://gitcode.com/gh_mirrors/fp/fprime点击查看免费下载导读F´F Prime是一个面向飞行软件与嵌入式系统的开源框架。本文以仓库内 CMake 构建系统软件设计文档 为主体系统讲解 F´ 基于 CMake 的全新构建系统它为何取代继承自 JPL 火星科学实验室MSL任务、已存在十余年的旧构建系统具备哪些明确的构建需求以及把 F´ 当作库的三种操作范式如何落地。结合仓库中 cmake/FPrime.cmake、cmake/API.cmake、cmake/module.cmake 等源码你将掌握 F´ 模块/可执行程序/单元测试的注册机制、CMake 文件组织方式以及如何为 F´ 添加新组件、新拓扑与新平台。1 背景与目标为什么 F´ 需要一套新构建系统F´ 的旧构建系统继承自 JPL 火星科学实验室MSL任务创建于十多年前。随着 F´ 的演进旧系统难以增强和维护的问题日益突出因此 F´ 引入了基于流行开源工具 CMake 的新构建系统。本文档Software Design DocumentSDD给出了该构建系统的一组需求、若干操作概念以及候选的构建系统设计。新构建系统要解决的核心痛点包括模块构建顺序旧系统要求显式指定全部模块的顺序而 F´ 模块众多显式排序十分困难配置隔离旧系统存在全局 make 配置目录的问题不同部署无法独立配置依赖扩展成本旧构建系统学习曲线陡峭新增组件成本高构建形态单一F´ 不仅有部署deployment还有可执行工具、库、单元测试等多种产物。1.1 术语定义SDD 中以下术语具有特定含义是理解后文的基础术语含义Host用于构建代码的机器或架构Target代码为之构建的机器或架构Build Commands通过 make 系统运行的命令In-Source Build在源码旁生成构建产物Out-Of-Source Build在独立于源码的目录中生成构建产物Build Configurations不同的构建设置如不同目标、调试标志、不同部署通常彼此隔离F´ ModuleF´ 组件与 F´ 端口的超集Deployments包含框架、旨在以 F´ 形式运行的 F´ 二进制/可执行文件Executable由构建系统构建的二进制不旨在作为 F´ 部署运行2 构建需求清单RequirementsSDD 以需求表的形式定义了新构建系统必须满足的能力每项都标注了验证方法与当前状态是判断该系统设计完成度的重要依据。完整清单如下需求描述理由验证方法状态BUILD-01构建系统应支持在 Linux 和 Mac OS 上进行原生 F´ 构建和安装JPL 的 F´ 开发在 Linux 和 Mac OS 上进行InspectionDoneBUILD-02构建系统应提供支持其他 Host 操作系统的模板模板使添加主机更容易InspectionDoneBUILD-03构建系统应提供支持其他 Target 的模板模板使添加新目标更容易InspectionDoneBUILD-05构建系统应提供交叉编译目标示例交叉编译在 JPL 很常见必须提供示例InspectionDoneBUILD-06构建系统应支持自定义构建命令自定义构建命令允许扩展构建系统InspectionDoneBUILD-07构建系统应支持单个组件、端口和拓扑的构建编译特定组件可加速开发Unit TestDoneBUILD-08构建系统应支持单元测试构建和运行系统检查单元测试对正确开发至关重要Unit TestDoneBUILD-09构建系统应支持构建部署部署必须正确构建Unit TestDoneBUILD-10构建系统应支持与其他构建系统集成有些库自带其他 make 系统Included within CMakeDoneBUILD-11构建系统不应要求所有模块按特定顺序构建当必须显式指定时排序所有 F´ 很困难InspectionDoneBUILD-12构建系统应支持 F´ 的独立 out-of-source 构建构建产物通常与源码分开保存InspectionDoneBUILD-13构建系统应支持可执行文件和工具构建并非所有 F´ 都是部署InspectionDoneBUILD-14构建系统应支持输出、头文件和库的安装与分发二进制输出的交付对项目很重要InspectionNeededBUILD-15构建系统应支持用户可配置的构建如 debug、release 等F´ 可能需要不同构建变体用于调试InspectionWork-AroundBUILD-16构建系统应易于使用包括添加新组件F´ 现有构建系统学习曲线陡峭InspectionDoneBUILD-17构建系统不应明显缓慢编译时间不可忽视InspectionDoneBUILD_18部署应独立配置依赖当前 F´ 存在全局 make 配置目录问题InspectionDoneBUILD_19构建系统不应难以设置和配置将现有 F´ 部署移植到新 make 系统不应需要大量工作InspectionDoneBUILD_20构建系统应支持将 F´ 作为库、子仓库和子目录使用即使 F 是只读的未来 F´ 使用应将核心视为输入InspectionDoneBUILD_21构建系统应支持 Windows 主机未来希望支持 Windows 构建InspectionNeededBUILD_22构建系统应支持构建子拓扑子拓扑是未来期望InspectionRemoved注需要 Autocoder 功能支持BUILD_23构建系统应支持将 F´ 核心构建为一组共享库未来某些任务可能受益于共享 F´ 核心InspectionDoneBUILD_24构建系统应支持 UT 和验证阶段钩子验证和对单元测试支持的增强有益于更好的项目开发InspectionNeededBUILD_26构建系统应支持执行单个、一组或所有基于 gtest 的单元测试DoneBUILD_27构建系统应支持 F´ Autocoder 的显式和隐式执行DoneBUILD_28构建系统应验证所需的编译器、链接器、库等已安装在执行构建的主机上DONEBUILD_29构建系统应实现旧 F´ 构建系统的所有用户目标Deferred需要单独的构建命令BUILD_30构建系统应支持执行单个、一组或所有基于 GSE 的集成测试注这是 GDS/GSE 流程而非构建流程。使用 fprime-gds 很容易实现BUILD_31构建系统应支持执行单个、一组或所有 F´ Autocoder 及关联工具测试Done从表中可以看到绝大多数核心需求已完成Done仅 BUILD-14安装/分发、BUILD-15构建变体目前为变通方案、BUILD-21Windows、BUILD-24UT/验证阶段钩子、BUILD-29旧系统全部用户目标已推迟等仍处于未完成或待定状态这为后续迭代指明了方向。3 操作范式Operations Concepts三种使用 F´ 的方式CMake 可以三种方式运行代表使用 F´ 的不同范式。核心区别在于构建产物对象、库、归档、makefile有时还有自动生成代码放在哪里Out-of-Source 构建产物放在与源码分离的目录中In-Source 构建产物与源码放在一起。现代构建系统强烈不鼓励甚至禁止 in-source 构建因为内容管理、构建配置、版本控制和开发都会因此变得更困难。CMake 系统允许 in-source 构建但仅当精确地按旧 make 系统的运行方式操作时才可行。因此共有三种操作范式推荐将 F´ 视为库执行 out-of-source 构建将项目代码直接加入 F´仍执行 out-of-source 构建强烈不鼓励将代码加入 F´进行 in-source 构建。注意与旧 make 系统并存时这无法工作。不同的构建配置不同目标、不同 cmake 选项、不同部署、debug 构建等通常放在不同的构建目录中如build_raspi_debug使所有配置与输出完全隔离——既不会产生链接混淆或构建冲突也不会因状态被遗忘而构建出错误的东西。范式 1 和 2 天然支持这种隔离而范式 3in-source则必须在切换时清除一切构建产物因此被强烈不鼓励。3.1推荐将 F´ 作为库使用 Out-Of-Source 构建在该设计中F´ 作为项目的一个子目录被包含。所有适配代码都放在 F´ 目录之外从而可以顺畅地更新、打补丁、冻结 F´ 核心组件并可轻易扩展为将 F´ 作为库链接。构建在用户指定的目录中进行用户创建命名的构建目录然后向 cmake 提供配置参数完成构建设置。适配代码与核心顶层目录并排存在每种配置对应一个独立构建目录。每种构建类型只需设置一次之后可以反复执行 makecd project mkdir build_config1 cd build_config1 cmake ../path-to-deployment -Dconfiguration settings当代码或 make 文件发生变化时开发迭代期间可随时重跑cd project/build_config1 make单个组件的构建方法见下文3.3 out-of-source 构建单个组件。3.2 传统 F´ 组织方式 Out-Of-Source 构建在该设计中F´ 核心与适配代码都放在 F´ 目录中这是使用 F´ 的传统方式。它不那么容易把 F´ 作为库使用且更新 F´ 时略显困难但除此之外是一种稳定可靠的方法。使用方式与 3.1 几乎相同唯一区别是所有代码都在 F´ checkout 内这要求完整 fork F´。cd fprime mkdir build_config1 cd build_config1 cmake ../path-to-deployment -Dconfiguration settingscd project/build_config1 make3.3 Out-Of-Source 构建单个组件在 out-of-source 构建中构建 F´ 内的单个组件时需要切换到并行的构建结构中以找到组件的构建目录F´ 核心组件位于build/F-Prime/path-to-component适配组件通常位于build/adaptation/path-to-component然后在该目录中执行 make 即可构建该组件。单独构建 F´ Svc 组件cd build_config1/F-Prime/Svc/FatalHandler make单独构建 Ref 组件cd build_config1/Ref/PingReceiver/ make这种能力对应需求 BUILD-07支持单个组件、端口和拓扑构建——编译特定组件可显著加速开发迭代。3.4强烈不鼓励旧式 In-Source 构建该范式仅为不破坏旧 F´ 工作流而保留带有若干警告它不能与旧 make 系统并行运行会覆盖旧 make 系统的产物重新配置构建设置必须删除所有构建与 CMake 产物切换构建配置时可能出现链接和构建错误。cd fprime git clean -xdf . # 警告这会清除*所有*未跟踪文件 cmake ../path-to-deployment -Dconfiguration settings make每次运行构建时必须执行以上命令以防错误和不可预测的构建。然而清除构建系统的全部产物过于粗暴——配置会丢失或污染新构建这正是本范式被强烈劝阻的原因。若确实需要采用务必理解上述警告并具备应对负面后果的安全机制。3.5 添加新组件与拓扑新组件可通过在组件目录中创建CMakeLists.txt文件来添加。该文件必须设置两个 CMake 变量SOURCE_FILES作为源码或自动编码autocoding源文件的文件列表MOD_DEPS可选模块和链接依赖列表。使用 CMake 的set()函数设置最后调用 F´ 的 CMake 支持函数register_fprime_module它负责设置自动编码步骤并确保该组件作为 F´ 模块构建。模块 CMakeLists.txt 示例# Default module cmake file # SOURCE_FILES: Handcoded C source files set(SOURCE_FILES ${CMAKE_CURRENT_LIST_DIR}/PingReceiverComponentAi.xml ${CMAKE_CURRENT_LIST_DIR}/PingReceiverComponentImpl.cpp ) # Note: no MOD_DEPS needed. register_fprime_module()仓库中 Ref/PingReceiver/CMakeLists.txt 就是这一模式的现代版本它把.fpp自动编码输入与手写实现.cpp一并列入SOURCE_FILES由于依赖可由自动编码输入自动推断因此无需MOD_DEPS即可直接调用register_fprime_module()。该文件必须通过add_subdirectory加入某个父级CMakeLists.txt。若是新 F´ 组件通常加入该组件所在顶层目录的CMakeLists.txt如fprime/Svc/CMakeLists.txt这些子级 CMakeLists.txt 是便捷性的存在由 FPrime.cmake 自身包含。若没有方便的列表文件组件可直接加入fprime/cmake/FPrime.cmake非核心组件则必须加入部署的CMakeLists.txt或从其包含的子文件加入。示例添加子目录add_fprime_subdirectory(${CMAKE_CURRENT_LIST_DIR}/PingReceiver/)拓扑CMakeLists.txt与模块文件格式相同但有两点偏差首先MOD_DEPS通常需要定义因为某些依赖无法自动检测、必须显式选择其次调用的是register_fprime_executable因为将生成可执行文件。拓扑 CMakeLists.txt 示例# Default deployment cmake file # SOURCE_FILES: Handcoded C source files # MOD_DEPS: Modules needed by this deployment set(SOURCE_FILES ${CMAKE_CURRENT_LIST_DIR}/RefTopologyAppAi.xml ${CMAKE_CURRENT_LIST_DIR}/Topology.cpp ) set(MOD_DEPS Svc/PosixTime Svc/PassiveConsoleTextLogger ) register_fprime_executable()仓库中的真实例子见 Ref/Top/CMakeLists.txt它把instances.fpp、topology.fpp、RefPackets.xml作为自动编码输入把RefTopology.cpp作为手写源码并显式声明了Fw/Logger、Svc/PosixTime以及Drv/Udp、Drv/TcpClient、Drv/TcpServer等通信实现依赖。这些文件同样必须加入入口CMakeLists.txt或其子文件。4 CMake 构建组织Build OrganizationCMake 系统由三部分组成入口文件由部署或可执行程序提供图中黄色来自部署/可执行程序通常由 F´ 适配项目提供F´ 核心 CMake 支持文件图中绿色提供构建组件、部署、模块的核心 CMake 函数CMakeLists.txt 文件图中蓝色/橙色用于构建核心与适配的 F´ 组件和拓扑。4.1 部署与可执行程序的 CMake 文件这些文件由被构建的部署或可执行程序提供承担两项关键职能职能一提供构建系统的入口。包含标准 CMake 头部和 F´ CMake 支持文件FPrime.cmake的包含语句还应包含FPrime-Code.cmake以纳入 F´ 核心代码确保 CMake 就绪且所有 F´ 设置已包含。典型的入口文件如下CMake 头部与 F´ 构建系统## # Section 1: Basic Project Setup # # This contains the basic project information. Specifically, a cmake version and # project definition. ## cmake_minimum_required(VERSION 3.16) project(FPrime-Ref C CXX) ## # Section 2: F´ Core # # This includes all of the F´ core components, and imports the make-system. F´ core # components will be placed in the F-Prime binary subdirectory to keep them from # colliding with deployment specific items. ## include(${CMAKE_CURRENT_LIST_DIR}/../cmake/FPrime.cmake) include(${CMAKE_CURRENT_LIST_DIR}/../cmake/FPrime-Code.cmake)仓库中 Ref/CMakeLists.txt 是这一结构的完整真实实现它在 Section 1 声明cmake_minimum_required(VERSION 3.16)与project(Ref VERSION 1.0.0 LANGUAGES C CXX)在 Section 2 先include上述两个核心文件其注释特别指出自定义 target 需在两个 include 之间注册并在 Section 3 通过add_fprime_subdirectory加入 PingReceiver、RecvBuffApp、SendBuffApp、SignalGen、TypeDemo 等组件目录与 Top 拓扑目录最后以register_fprime_deployment()注册部署MOD_DEPS为${PROJECT_NAME}/Top。职能二包含包含适配特定 F´ 组件的子目录。这与 F´ 核心子目录包含方式相同但代表适配特定组件## # Section 3: Components and Topology # # This section includes deployment specific directories. This allows use of non- # core components in the topology, which is also added here. ## # Add component subdirectories add_fprime_subdirectory(${CMAKE_CURRENT_LIST_DIR}/PingReceiver/) add_fprime_subdirectory(${CMAKE_CURRENT_LIST_DIR}/RecvBuffApp/) add_fprime_subdirectory(${CMAKE_CURRENT_LIST_DIR}/SendBuffApp/) add_fprime_subdirectory(${CMAKE_CURRENT_LIST_DIR}/SignalGen/)注意组件的输出被路由到构建中以Ref前缀开头的命名子目录。4.2 F´ 核心 CMake 支持文件这些文件提供构建组件、部署和模块所用的核心 CMake 函数。此外FPrime-Code.cmake包含组成 F´ 核心组件的子目录使部署只需包含这一个 CMake 文件即可导入整个 F´。自动化自动编码auto-code的函数、模块依赖处理及各种其他工具也都包含其中。因此部署和可执行程序在添加自定义组件时可遵循与 F´ 核心组件相同的模式。从源码看cmake/FPrime.cmake 是系统真正的入口它通过include_guard()保证只加载一次依次包含utilities、options、sanitizers、required加载平台设置然后包含module、autocoder/autocoder、target/target、API、sub-build/sub-build、settings等模块。其中的fprime_initialize_build_system宏完成了关键初始化设置全局 include 目录框架、配置、项目根与构建缓存、检测外部库、注册标准 targetbuild、FPP/XML/Packets 三类 autocoder、version、install、ut以及可选的 refresh_cache 与 check。fprime_setup_included_code则负责把 F´ 核心包Fw Svc Os Drv CFDP Utils与config目录、googletest、STest、Autocoders依次加入构建。4.3 F´ 核心与适配的 CMakeLists.txt 文件这些文件用于指定 F´ 组件、端口和拓扑的构建布局按层级组织见下图。它们调用 F´ 的模块与部署函数以生成预期构建文件格式已在 3.5 节描述链接源文件与自动编码器输入到生成函数由这些函数组装 F´。5 CMake 架构Architecture如前所述F´ 的大部分构建魔法封装在 CMake 工具函数中。架构中有两组主要函数每组都包含执行生成工作的原始函数generate_*和包装它们的 API 包装器register_*register_fprime_module/generate_module源码中为generate_library生成库/模块构建文件与依赖register_fprime_executable/generate_executable生成可执行程序构建与依赖。注意图中颜色继承自前述示意图红色为输出产物紫色代表执行步骤。5.1 模块函数register_fprime_module 与 generate_module模块函数旨在将 F´ 目录构造成一个库静态或共享。模块名由目录路径相对于仓库根目录的位置决定例如Fw/Comp变为Fw_Comp产物为libFw_Comp.a。该库作为 CMake 系统的输出添加由SOURCE_FILES构建——这些文件被拆分为自动编码器输入.xml、.txt、.fpp和普通源文件。特定依赖可通过MOD_DEPS提供但仅当依赖无法通过对自动编码文件中的全部.xmlinclude 做递归搜索而检测到时才需要。系统为每个自动编码输入文件注册自动编码生成步骤这些输入也用于检测模块的全部依赖普通源文件则提供给构建目录。这些步骤完成后CMake 生成主机特定的构建文件封装该模块的自动编码器调用、依赖与源文件。运行这些构建文件即生成模块库供部署链接阶段使用并注册到 CMake 以便参与全局依赖汇总。源码佐证cmake/module.cmakegenerate_library(MODULE_NAME SOURCE_FILES DEPENDENCIES)与generate_executable、generate_deployment、generate_ut都经由generate_base_module_properties落地该函数按目标类型Library/Executable/Deployment/Unit Test创建底层 target设置FP_TYPE属性并调用setup_module_targets完成源文件拆分、自动编码与依赖装配。5.2 可执行函数register_fprime_executable 与 generate_executable可执行函数旨在创建可执行程序。这些可执行程序拥有确定的源文件并自动把所有依赖汇总到一个全局有序的依赖列表。可执行程序名来自创建 CMake 项目时定义的${PROJECT_NAME}否则必须单独提供。可执行程序可提供SOURCE_FILES与MOD_DEPS可使用自动编码其余行为与上述模块类似唯一区别是构建输出为可执行程序。注意部署指定一个或多个可执行程序这些可执行程序成为依赖树的根。因此只生成所需的可执行程序、库与输出而不会显式构建整个 F´ 系统这使得构建更高效对应 BUILD-17。在 cmake/API.cmake 中register_fprime_executable与register_fprime_deployment均要求先定义SOURCE_FILES或MOD_DEPS可执行程序名优先取EXECUTABLE_NAME/传入参数否则回退到FPRIME_CURRENT_MODULE或PROJECT_NAME。register_fprime_deployment的 API 注释还特别说明部署几乎总是需要通过MOD_DEPS提供拓扑模块如${FPRIME_CURRENT_MODULE}/Top且不得把可执行目标放进MOD_DEPS会导致多重main定义等链接问题应改用 CMake 原生的add_dependencies建立纯 CMake 依赖。5.3 单元测试函数register_fprime_ut注册单元测试使用与上述相同的过程区别在于变量UT_SOURCE_FILES和UT_MOD_DEPS这允许同一文件既定义模块或可执行程序、又定义单元测试而不覆盖先前使用的变量。单元测试必须使用TESTING这一 cmake 构建类型构建以启用单元测试构建并设置make check目标。这既防止单元测试拖慢正常构建也允许为 UT 使用专门的编译标志。UT 注册到make check目标以支持一次性运行单个 UT 可按需从bin目录运行。建议从 F´ 顶层构建会拉入所有单元测试从部署构建则适合运行该部署的单元测试。UT 构建示例mkdir build_ut cd build_ut cmake .. -DBUILD_TESTINGON make -j32源码佐证register_fprime_ut在BUILD_TESTING未开启或__FPRIME_NO_UT_GEN__置位时直接返回UT 可执行文件默认命名为MODULE_NAME_ut_exe并支持UT_INCLUDE_GTEST、UT_AUTO_HELPERS等开关。真实用例见 Svc/ActiveLogger/CMakeLists.txt——它在注册模块之后用UT_SOURCE_FILES同时列出被测试的ActiveLogger.fpp模型与test/ut/下的两个 Tester 源文件随后调用register_fprime_ut()。5.4 添加新平台Adding New PlatformsCMake 允许在初始 CMake 步骤中指定工具链toolchain因此编译新的目标 OS 核心上只需cmake path to deployment -DCMAKE_TOOLCHAIN_FILEpath/to/toolchain_file然而仅这样添加工具链会忽略 F´ 为编译平台特定代码所做的一些便捷设置因此用户还必须注册一个平台文件。在fprime/cmake/platform/目录下创建platform.cmake文件即可定义新平台。工具链文件如需随 F´ 提供可加入fprime/cmake/toolchain/。源码佐证cmake/platform/platform.cmake平台解析的实际流程是——原生工具链使用系统名如 Linux、Darwin作为FPRIME_PLATFORM交叉工具链必须把CMAKE_SYSTEM_NAME设为Generic并设置FPRIME_PLATFORM否则直接报错。随后系统按项目根 → 库 → 框架的顺序查找cmake/platform/${FPRIME_PLATFORM}.cmake并加载找不到则给出明确的FATAL_ERROR。仓库当前内置了 Linux.cmake、Darwin.cmake、rtems5.cmake等平台文件并提供platform.cmake.template模板供新平台参考。5.5 常用构建选项让 CMake 配置更灵活SDD 主文中未展开、但实际构建中高频使用的选项集中在 cmake/options.cmake这里做补充说明。所有选项均通过-DOPTIONVALUE传入值通常为 ON/OFFfprime-util会自动设置其中一部分其余可通过fprime-util的-D透传选项默认值作用CMAKE_DEBUG_OUTPUTOFF输出 F´ CMake 集成的调试信息用于排查构建系统问题FPRIME_USE_STUBBED_DRIVERS平台决定ON 使用桩驱动serial/ipv4 驱动除外OFF 使用完整驱动实现FPRIME_USE_BAREMETAL_SCHEDULER平台决定ON 使用裸机单上下文调度器OFF 使用 OS 线程调度FPRIME_ENABLE_UTIL_TARGETSON启用check、refresh_cache等 fprime-util 目标FPRIME_ENABLE_FRAMEWORK_UTSON是否把 F´ 框架自身的 UT 加入目标列表FPRIME_ENABLE_AUTOCODER_UTSOFF是否同时启用 Autocoder 工具自身的 UTFPRIME_ENABLE_UT_COVERAGEON是否计算单元测试覆盖率FPRIME_ENABLE_TEXT_LOGGERSON是否构建 ActiveTextLogger/PassiveConsoleTextLogger 文本日志组件FPRIME_SKIP_TOOLS_VERSION_CHECKOFF跳过 F´ 工具版本检查高级选项ENABLE_SANITIZER_ADDRESS/LEAK/UNDEFINED_BEHAVIOR/THREADOFF为整个构建添加对应的 Sanitizer 编译/链接标志此外options.cmake还定义了四个关键路径变量——FPRIME_FRAMEWORK_PATHF´ 框架安装位置、FPRIME_PROJECT_ROOT项目根用于 C include 相对路径、FPRIME_LIBRARY_LOCATIONS分号分隔的外部库位置列表、FPRIME_CONFIG_DIR配置头文件目录——它们通常由fprime-util提供直接在 IDE 或裸 CMake 中构建时才需手工指定。另一个重要的构建行为是当CMAKE_BUILD_TYPE为TESTING时BUILD_TESTING自动开启这正对应 5.3 节UT 必须用 TESTING 构建类型的设计。5.6 真实模块中的条件编译与平台适配模块CMakeLists.txt不只是静态罗列源文件还可以根据构建选项/平台动态选择实现。例如 Svc/FatalHandler/CMakeLists.txt基础源文件为FatalHandler.fpp与FatalHandlerComponentCommonImpl.cpp随后依据FPRIME_USE_BAREMETAL_SCHEDULER、CMAKE_SYSTEM_NAMEVxWorks等条件追加 Baremetal、VxWorks 或 Linux 的实现文件最后声明Os与Fw/Logger两个MOD_DEPS并注册模块。这体现了 CMake 系统与 F´ 平台抽象Os/Models/Models.hpp 所定义的Os_Task、Os_FileSystem等接口协同工作的方式接口由框架定义实现由平台与部署按需选择。6 总结F´ 的 CMake 构建系统是一次围绕易扩展、易维护、配置隔离的彻底重构它以 31 条需求明确边界以三种操作范式覆盖库化使用/传统使用/旧式 in-source三种场景以register_*/generate_*两组函数完成模块、可执行程序、部署与单元测试的注册与生成并通过FPrime.cmake、FPrime-Code.cmake、options.cmake、platform.cmake等支持文件实现自动编码接入、依赖推断、平台适配与全局目标装配。对开发者而言新增组件只需一个设置SOURCE_FILES与MOD_DEPS、调用register_fprime_module()的CMakeLists.txt构建部署只需一次cmake配置加反复make单元测试则以BUILD_TESTINGON的 TESTING 构建类型与make check统一驱动。这套设计既是理解 F´ 现有工程实践的钥匙也为在 F´ 之上构建自己的飞行软件部署提供了完整、可复制的构建骨架。赞分享嵌入式系统编程【免费下载链接】fprimeF´ - A flight software and embedded systems framework项目地址https://gitcode.com/gh_mirrors/fp/fprime点击查看免费下载相关推荐F´ 飞控软件框架 CMake 构建系统设计与实践指南F´ 飞控软件框架 CMake 构建系统设计与实践指南 本指南以 F´F Prime开源仓库中的 CMake Build System 软件设计文档SDD嵌入式系统编程MoE模型压缩的未来REAP方法为何成为专家剪枝的黄金标准 MoE模型压缩的未来REAP方法为何成为专家剪枝的黄金标准 在人工智能模型飞速发展的今天 MoE模型压缩 技术正成为提升大模型效率的关键突破。本文将深CMake源码架构深度解析从模块化设计到构建系统的完整指南CMake源码架构深度解析从模块化设计到构建系统的完整指南 CMake作为当今最流行的跨平台构建系统工具其源码架构体现了现代软件工程的精髓。本文将从CMak构建工具开发工具CLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考