网站排名优化价格,手机主页网站推荐,北京 网站设计飞沐,装修公司网站wordpress 模板对软件项目的构建#xff0c;也就是build过程#xff0c;就是对一堆源代码进行编译#xff0c;生成最终可执行程序或库。Java和C不一样#xff0c;不是编译型语言#xff0c;是解释型语言#xff0c;但都需要一个build过程。 下面以C/C语言为例来对代码的条件编译进行分析…
对软件项目的构建也就是build过程就是对一堆源代码进行编译生成最终可执行程序或库。Java和C不一样不是编译型语言是解释型语言但都需要一个build过程。 下面以C/C语言为例来对代码的条件编译进行分析。 第一种情况单个项目的构建源文件结构如下 main.c moduleA.c moduleB.c ...... ...... 这是单个项目包含全部的源码进行编译每个源文件会生成obj文件再将这些obj文件进行链接生成最终的可执行文件。这种方式就是所有的obj文件的内容整合到一起生成二进制可执行文件或库文件。所以如果object文件中在同样作用域中有重名的符号就会编译错误。C和C的符号系统是不同的比如C的函数符号的签名里使用了函数参数而C语言就没有。C可以有不同参数列表的同名函数而C就不可以有同名函数即使参数列表不同。C/C的函数签名和函数返回类型无关。 针对这种情况只是最简单的软件项目而从产品角度讲产品的功能是由软件和硬件共同完成的。比如通用型的PC上运行的软件或者各种嵌入式电子设备上跑的软件。通用型的PC硬件平台都有一套规范和标准比如键盘、显示器、网口、USB接口等即使硬件上有差异比如CPU架构不同等也会在操作系统上进行隔离所以同样的软件行为是一样的。这是对庞大的PC市场的一种适配性和兼容性的管理。而对嵌入式设备来说因为硬件配置可能各不相同所以同样的软件体现在产品上行为就会不同比如软件控制GPIO输出电平信号有的硬件配置是使用的LED灯做外设终端有的使用蜂鸣器做外设终端。 或者这样理解软件是基于一定的输入进行运算等处理然后将结果输出。而输入输出的接口的功能和模式是依赖于硬件提供的并且软件的运行也是基于硬件平台。软件基于硬件而设计和实现硬件需要适配软件的接口模式和兼容运行平台。 第二种情况软件项目集合的构建。这种情况对应的一般是多个产品比如嵌入式电子产品中的多个型号或一系列的产品。这些产品共用一套代码库按软件架构、功能等将代码库分成各个组件不同产品会复用这些组件。不同项目会根据不同配置来进行构建。编译出来的软件会适配相应的的硬件接口包括主芯片架构、相关外设等。整个产品的行为则由相应的硬件和软件共同决定。 相比上面第一种所有源文件参与编译和使用固定的构建过程第二种情况下会根据项目或产品不同执行不同的构建过程。比如使用Keil或IAR来创建工程时不同的产品会使用不同的工程文件还会按照功能区别选择添加不同组件以及组件内的的源文件。一些源文件可以是此项目特有的一些源文件是公用的。通过管理变和不变使得各个项目的代码都在一个代码仓库中方便管理和复用。如果使用Makefile的构建方式原理也是类似的Makefile就相当于工程文件。通过传入变量给Makefile或CMake来改变build脚本的行为。 每套单独的硬件是固定的而软件是灵活的。软件的许多源文件可以按组件分类再按照构建需要选择组件并进行相应的设置编译最终的可运行软件。这种构建时的要求就比较高复杂度也高一些。比如要使用Make、CMake等工具来对构建过程进行管理。 构建完成的目标软件可以不止适配一套硬件也可以适配多套硬件比如主芯片相同、外设功能不同的相似硬件。这样构建出的软件可以认为是多套硬件对应的单个软件所组合起来的超集。比如Linux里使用的Device Tree技术就是将硬件信息通过bootloader传给kernelKernel会加载不同的硬件驱动并且在Linux运行的APP也可以根据不同的硬件信息提供不同的功能。这是软件的增量式构建一套软件多种用途。而很多时候我们也需要减法操作在融合了多个项目的代码仓库中为某个产品编出一个不多不少的恰到好处的目标软件就如整篇文章所讲述的情况。 第三种情况基于第二种情况引入了库。在构建相应项目时将每个模块编译成静态库其他源码使用头文件来引用库的功能。做成静态库库里面没有使用到的object文件就不会被链接进来。 项目结构如下 main.c libA.a (moduleA.c) libB.a ( moduleB.c) ...... ...... 将编译出的obj文件打包就会生成静态库。命令是 $ gcc -c -o out.o out.c $ gcc -c a.c b.c c.c $ ar rcs libout.a out.o a.o b.o c.o 如果在链接过程中使用了静态库的话和链接object文件不同不是所有内容最后都会被链接到最终可执行文件中没有使用到的代码比如函数或变量是不会包含到最终的可执行文件中的。 使用了静态库在编译期来决定某个源文件是否可能被使用。以C代码为例如果使用了某个子类那父类的代码也需要就会编译进来。 这里会出现一个问题将某个组件加入到可执行软件中是需要调用组件的相关函数才行。那不需要使用的组件就不要调用。 第四种情况理想情况下各个组件是按需参与构建不要的组件就不会包含到最终软件中。但由于软件功能的复杂性各个组件之间会存在各种耦合。比如互相之间存在函数调用。在实际运行中某组件并不会使用但在编译期从代码分析上却体现不出来。这就导致不被使用的组件也会参与编译并被链接进最终的可执行软件。 这样就需要从代码层面来解决组件之间的耦合问题尽量在软件设计上避免或减少组件间的互相依赖。比如通过引入一个中心消息组件来减少组件之间的直接函数调用而改为收发消息。代价就是可能会降低软件性能。如果每个组件是独立进程就要使用进程间通信来处理组件间通信处理耦合反而容易。如果每个组件是属于不同线程或直接使用轮循方式执行任务处于同一内存空间则组件之间很容易直接调用执行和开发效率很高但增加了软件的熵。有一种方法可以给每个组件的窗口模块(源文件)或窗口类加一个空实现。如果不要这个组件那就选择这个空实现的模块文件或类文件参与构建。如果要使用这个组件在构建时就把正常的窗口类包含进来参与编译。 还有一种方法 使用预处理宏作为编译开关将组件中的耦合代码进行隔离。正常情况下应该有一个关键的调用接口层比如上面的窗口类将这些代码注释掉就应该可以了。这个编译开关是在编译时的命令行参数中加入的宏定义。这种要改代码引入了额外的工作量。需要评估。 如果是需要一个恰如其分的不引入多余源码的目标软件在决定引入组件的主函数或窗口类的关键代码处就应该注意。不使用这个组件的话就不要引入。否则就可能把这个组件的大部分代码包含进来了。你引入了组件主函数或窗口类但其实后面又没用到就亏了。这部分代码可以每个产品或项目使用不同的源码文件。或者代码里使用项目或产品的编译开关来控制组件的引入与否。 能在编译期通过构建脚本来管理不同项目参与编译的源文件是更好的一个地方把这个问题都解决。而不要在代码层面引入编译开关和修修改改这会添加不必要的信息也让阅读代码的人产生困惑。 实际操作举例 1我们使用cmake来构建项目在构建时传给cmake一个项目参数比如machine name。 2在cmake中使用optiotn函数设定一些选项用于描述machine的功能。后面将这使用这些选项来选择参与构建的组件、选择组件内参与构建的源文件以及定义源文件内使用的编译开关。 3在cmake中根据machine name来设置option项。 4在cmake中通过add_definitions命令通过命令行参数在编译源文件时加入编译开关。 构建命令 $ mkdir build $ cd build $ cmake ../ -DMACHINEAPPLE_DEVICE $ make CMakeLists.txt option (FEATURE_WIFI Wifi OFF) if (${MACHINE} STREQUAL APPLE_DEVICE) set(FEATURE_WIFI ON) endif() if(FEATURE_WIFI) add_library(wifi src/wifi_main.c src/wifi_driver.c src/wifi_msg.c ) endif() if(FEATURE_WIFI) add_definitions(-DENABLE_WIFI1) endif() 代码里 int communication_wifi(void) { #if ENABLE_WIFI // Call Wifi function #endif return 0; }
