工程化实践:构建嵌入式Linux应用开发环境与基础设施

本文将对嵌入式 Linux应用开发环境与基础设施进行系统性介绍。这套工作流笔者已稳定使用数年，经受了多个量产项目的实际检验。

准备工作

Windows下提前安装如下软件：

1. VMware（在虚拟机中安装ubuntu）
2. 终端工具MobaXterm（用于SSH到ubuntu）
3. Visual Studio（安装Visual Assist插件）

我们日常编码与开发均在Windows环境下完成，仅在需要构建正式版本时，才通过SSH登录ubuntu服务器，通过执行代码库中的构建脚本生成交叉编译后的目标可执行程序。

在此之前我们还需要将代码库所在目录设置为共享文件夹，将其映射到虚拟机 /mnt/hgfs 目录下，然后在Linux命令行下执行：

sudo mount -t fuse.vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other

这样就能实现文件双向实时同步。

代码库物理设计

代码库的物理设计决定了团队协作的效率与项目的可维护性。

合理的目录结构应当清晰反映系统架构，同时兼顾构建系统的简洁性。以下是一套经过实践验证的组织方式：

.├── 10-common│   ├── build     │   ├── doc│   ├── include│   ├── lib│   └── version├── 20-sdk│   ├── protolib│   ├── dblib│   ├── robotlib│   └── tpslib├── 30-client│   └── teach_pendant├── 40-servers│   ├── servers_robot│   └── servers_rt└── 50-tool    ├── build    ├── oom_killer    ├── pkg_maker    ├── protocol_test    └── status_code

在这里我们的目录以数字为前缀，这种风格的核心优势在于：

直观体现模块关系 数字编码将抽象的架构约束转化为可视化的物理顺序。10-common 前置表明其为全局基础设施，后续模块按数字递增依赖前者，形成清晰的单向依赖链。新成员无需阅读文档，仅通过目录列表即可快速理解系统骨架。

构建编排天然有序 批量处理脚本可按数字glob模式（如 10-*、20-*）串行执行，确保底层库优先编译，上层模块随后链接。这种隐式顺序消除了手动维护构建清单的负担，也避免了循环依赖的引入——若某模块需引用更高序号目录，架构违规一眼可辨。

扩展预留与归类 十位间隔（10、20、30…）为演进保留插槽。新增模块时，可嵌入21、35等空位，无需重命名既有目录即可维持逻辑连续性。同时，数字前缀将功能分类（通用层、客户端、服务端、SDK、工具）与物理排序合二为一，比纯字母命名更具表现力。

工具链友好 文件管理器、终端补全、IDE项目树均按字典序排列，数字前缀确保关键基础设施始终置顶，减少视觉搜索成本。构建日志中的路径也因数字前缀而具备可读的时间线特征，便于快速定位问题模块。

简言之，这是一种将架构意图直接写入文件系统元数据的工程实践，以极低成本换取了团队协作与自动化维护的长期收益。

10-common

此目录为全局基础设施，该目录下的物理结构如下：

.├── build│   └── common.mk├── doc├── include│   ├── boost-1_75│   ├── gtest│   ├── tbox│   └── tftp├── lib│   ├── gtest│   ├── tbox│   │   ├── niic_r000a│   │   └── ubuntu64│   ├── tftp│   │   ├── niic│   │   ├── t113│   │   ├── ubuntu│   │   └── vanxoak│   └── uranus└── version    ├── debug    └── release

几个比较重要的目录如下：

• doc：用来存放一些接口文档，设计方案等
• include：用来存在公共库的头文件
• lib：用来存放公共库文件（同一库下区分不同平台）
• version：存放构建的版本

20-sdk和40-servers

sdk用来存放封装的动态库的源码，servers用来存放可执行文件的源码。

两者目录结构高度同源，层级组织方式保持一致，以servers_robot为例：

├── include├── prj_linux│   ├── build_ft.sh                      // 单元测试编译、运行脚本│   ├── cfg                              // 配置文件│   ├── makefile_necro_release           // necro平台makefile脚本│   └── makefile_ubunt64_ft              // ft makefile脚本├── prj_win│   ├── servers_robot.sln│   ├── servers_robot.vcxproj│   ├── servers_robot.vcxproj.filters│   └── servers_robot.vcxproj.user           ├── source└── test

几个比较重要的目录如下：

• include：存放内部头文件
• prj_linux：Makefile等脚本，被50-tool/build目录下的构建脚本调用
• prj_win： visual studio工程，只用来编辑代码
• source：程序源文件
• test：单元测试代码

30-client

由于项目中涉及到客户端，该目录用来存放客户端源码（基于QT），物理结构如下：

.├── bin├── build_release.sh├── cfg├── CMakeLists.txt├── Makefile├── resources├── src├── teach_pendant.pro├── teach_pendant.pro.user└── temp

50-tool

该目录用来存放一些工具和脚本，物理结构如下：

.├── build│   ├── build_pb.sh│   ├── build_pendant.sh│   ├── build_app_ft.sh│   ├── build_app_release.sh│   ├── pkg_pendant│   │   ├── mkpkg.sh│   │   ├── run.sh│   │   └── wd.sh│   └── pkg_app├── cmd_browse│   ├── rlCmdConvert.py│   ├── rlCmd.json│   └── rlCmd.xls├── oom_killer│   └── monitor.sh├── pkg_maker└── status_code    ├── logDisplay.json    ├── status_code_def.h    ├── status_code.py    └── status_code.xls

build目录下存放的都是脚本文件，用途如下：

1. 版本构建脚本，会调用每个sdk、可执行程序下的构建脚本
2. 软件升级包生成脚本

tool目录下还会放一些开发的小工具，这些工具可以是python脚本，也可以是用shell写的脚本，这里不展开。

代码编辑调试

在Windows平台进行代码编辑与单元测试调试时，通常需要在项目属性中配置以下四个关键编译选项：

由于我们是嵌入式开发，会有一部分代码和目标平台相关，而Windows环境必然会缺少对应的库版本支持，可通过从生成中排除特定文件的方式，避免编译错误并保持项目结构的完整性。附示例图：