由于各个芯片厂商发布SDK所使用的编译方式各不相同，开发者在开发过程中需要学习和适应不同编译环境，导致开发精力被分散。OneOS环境可以编译其他SDK应用代码，让开发者忽略编译影响，从而将精力聚焦在功能开发中。是不是很香~那么下面就跟着小编以展锐8910DM为例，学习如何把第三方SDK导入OneOS编译系统吧！

注意：以下分析基于8910_Module_V1.4和OneOS 2.0版本。

在正式导入前，让我们一起来了解第三方编译规则和OneOS Scons编译框架。

第三方编译规则

8910DM SDK使用的是cmake/ninja编译工具，它的编译脚本launch.bat首先配置了环境变量、编译链接工具、创建编译输出目录等：

为了保持SDK编译一致性，这些工具同样需要在OneOS中使用。接下来查看SDK编译链接目标及其规则。

cmake编译命令会把编译规则做初步解析，拷贝一些cmake文件，创建编译目标文件夹，并将原来的cmake编译规则转成ninja编译规则。cmake规则文件是CMakeLists.txt，而ninja 是build.ninja和rules.ninja。直接从build.ninja中可以找到链接目标及规则，例如编译C文件：

链接库文件：

Ninja编译使用的都是自定义命令，具体定义位于rules.ninja，如下：

build.ninja的语法规则比较直白，build后面跟着目标名字，冒号之后的编译命令用rules.ninja定义替换。我们需要关注的是目标文件和对应的依赖文件各有哪些，使用的编译链接选项包含哪些，这些都会在移植编译系统时用到。

OneOS scons 编译框架

OneOS 编译是在OneOS cube环境中执行的，使用的是scons编译系统，编译时先在project/xxxx/文件中打开OneOS cube，再执行配置/编译命令，如：

Scons框架

scons是基于python的脚本编译系统，在projects/xxxx/目录中主要由SConstruct和osconfig.py配置编译选项及步骤，各个源码目录下由SConscript决定编译模块相关文件及目标，类似于makefile。scripts/build_tools.py则实现了SConstruct使用到的所有函数，前面配置完成后，真正执行是靠这个脚本完成。

menuconfig

menuconfig命令执行时通过读取.confg文件获取当前的kconfig 配置信息，执行完成时把相关信息保存到oneos_config.h，其他模块通过 include 头文件使用相关设定值。这个过程是执行python脚本menuconfig.py实现的。

SConstruct

每个工程只有一个SConstruct脚本，它分为两部分，第一部分是编译配置，包括导入osconfig.py配置，build_tools.py配置，环境变量配置等，如：

编译前通过 Environment()创建新的编译环境，创建时初始化 AS/ASFLAGS(汇编)， CC/CCFLAGS(C 源码)， AR/ARFLAGS(库管理)， CXX/CXXFLAGS(C++编译)， LINK/LNIKFLAGS(目标链接)使用的工具及对应的编译链接选项。这个功能保证了不同的project使用不同的编译工具，而且能够自定义工具路径。具体设置将在 osconfig.py 中分析。

RESULT 是编译链接的目标文件，后缀由 osconfig.RESULT_SUFFIX 指定。接下来是启动编译：

SetupCompile()会把前面配置的内容保存，并解析各目录中的SConscript，返回需要编译的中间目标 objs.StartCompile()则根据中间objs编译生成最终目标文件RESULT。这一步主要依赖scons 的 program()函数实现。编译后调用 EndBuilding()执行postAction的命令，这个也可以在osconfig.py中定制化。细节可以去 build_tools.py 中研究。

osconfig.py

不同的 project 可以做不同的配置，还可以根据环境做多种配置，这个文件实现了这个目的。它的使用也很方便，任何需要用到的地方import osconfig 就可以了，包括Sconstruct、 SConscript脚本中都能直接使用。这为统一配置带来极大的便利。

环境变量

以上指定了编译环境属性，编译工具路径，链接库的路径等。

编译工具及选项

这部分主要是Sconstruct中提到的编译工具及编译选项的设定，它们会直接替换默认的scons编译工具

后编译命令

POST_ACTION是在Sconstruct指定的最终目标文件生成后，额外需要完成的工作。比如指定文件转移到out目录，img打包，pac文件打包等等，达到客制化的目标。

它可以是执行 python 脚本， bat 脚本，甚至是一句类 unix 命令。触发函数在 build_tools.py Env.AddPostAction()中。

转换流程

有了对两种编译系统的了解，现在让我们一起完成编译系统的转换吧！

总体来说，我们需要把 8910DM SDK 中的模块拿到 OneOS 环境中编译链接，同时 OneOS 自有模块也能一起打包成最终目标文件。最简单的方法是把 SDK 所有的库放到 OneOS 环境中， OneOS只编译自己的源码，最终把SDK的库和OneOS的.o全部link为目标文件（pac包）。

Step 1目标文件溯源

根据8910 build.ninja文件分析，目标文件生成流程如下：

1. 把.obj及静态库链接生成elf
2. 通过dtools工具把elf文件生成 img
3. 用签名工具vlrsignr把上一步的img签名得到sign.img
4. 最后用python3执行pacgen.py pac-gen命令把json文件及签名img生成pac文件，这个文件是最终烧入目标文件。

Step 2 复制编译工具

先整理全部编译相关工具， gcc相关的，python3，签名工具vlrsign，打包用的json和 pacgen.py，生成img用的dtools都从SDK拷贝到OneOS/thirdparty/8910dm/tools/目录：

osconfig.py中设置相关路径：

Step 3 编译选项

主要是 C 和汇编的编译选项，直接复制过来：

Step 4 链接选项

把链接 elf 的选项复制过来即可：

链接用到的静态库文件、obj文件，IMG文件及标准libc库文件也同时拷贝到thirdparty\8910dm\prebuilts\目录下。使用静态库时，对应的头文件需要拷贝到OneOS框架， 这里放在了thirdparty\8910dm\include_files\。

Step 5 post action

这步主要工作是把elf文件生成img文件并进行签名，最后所有img打包成pac文件。

postAction.bat的内容，复制了elf生成img、img签名、pac打包命令：

至此，整个编译系统移植完成了。