RT-Thread RTOS:新的命令行构建系统
对于大的工程来说，使用IDE来管理总是有诸多限制，例如大多少数IDE不能够支持在工程中存在相同文件名的文件（即使是路径不相同）。而且用IDE来做 build，其速度确实要慢了好几拍。RT-Thread 0.2.x以前都是采用的GNU Make + GNU GCC的方式来编译，但Makefile的组织太过复杂，特别是要做编译选项，会非常非常麻烦（编译选项不能够在多个Makefile之间自由传递）。 GNU还有一种方式，名为automake, autoconfig，不过当自动产生的Makefile比自己的代码还多的多的时，有时就不得不思考，程序员是在写代码，还是 automake&autoconfig在写程序员。
RT-Thread到0.3.x，主要的编译器切换到RealView ARM Compiler，所以默认没有发布出带Makefile的版本。当然最大的原因还是，Makefile太难以忍受了！为了达到更好编译的目的，尝试创建了一个小型的分支，这个分支完全采用的是新的scons构建系统（http://www.scons.org）：先有尝试，然后考察其实用性，最后实施。
现在到了实施的阶段：因为scons构建系统优点值得称赞，值得应用。scons的优点，英文的，这里就不翻译了：
What makes SCons better?
* Configuration files are Python scripts--use the power of a real programming language to solve build problems.
* Reliable, automatic dependency analysis built-in for C, C++ and Fortran--no more "make depend" or "make clean" to get all of the dependencies. Dependency analysis is easily extensible through user-defined dependency Scanners for other languages or file types.
* Built-in support for C, C++, D, Java, Fortran, Yacc, Lex, Qt and SWIG, and building TeX and LaTeX documents. Easily extensible through user-defined Builders for other languages or file types.
* Building from central repositories of source code and/or pre-built targets.
* Built-in support for fetching source files from SCCS, RCS, CVS, BitKeeper and Perforce.
* Built-in support for Microsoft Visual Studio .NET and past Visual Studio versions, including generation of .dsp, .dsw, .sln and .vcproj files.
* Reliable detection of build changes using MD5 signatures; optional, configurable support for traditional timestamps.
* Improved support for parallel builds--like make -j but keeps N jobs running simultaneously regardless of directory hierarchy.
* Integrated Autoconf-like support for finding #include files, libraries, functions and typedefs.
* Global view of all dependencies--no more multiple build passes or reordering targets to build everything.
* Ability to share built files in a cache to speed up multiple builds--like ccache but for any type of target file, not just C/C++ compilation.
* Designed from the ground up for cross-platform builds, and known to work on Linux, other POSIX systems (including AIX, *BSD systems, HP/UX, IRIX and Solaris), Windows NT, Mac OS X, and OS/2.
如上所说的，scons是构建在python脚本的基础上的，功能繁多。依赖于python，可以说在scons的脚本中能够做非常多的事，控制灵活。试用下来，感觉最大的是，其-j选项。因为现在的机器多大是多核的，而-j后，将大大的加快编译的速度，真正有那种在指尖飞的感觉。
进入正题，说说RT-Thread里的命令行编译如何使用
首先，需要安装python，http://www.python.org，2.5或2.6版本
其次，安装 scons，http://www.scons.org，可以先装个安装版本，以后自己会了只装zip，源代码版本即可。
再次，从 google svn中获取RT-Thread的最新代码，因为最近才实施scons构建系统。
因为每个人机器上的编译器不同，安装的目录也不相同，需要根据你的环境设定编译选项
打开RT-Thread代码中bsp\stm3210\rtconfig.py文件，修改如下选项：
PLATFORM = 'gcc'
EXEC_PATH = 'd:/SourceryGCC/bin'
即把PLATFORM设置为你使用的编译器，可设置为gcc或armcc (iar过一段时间支持)
EXEC_PATH设置为相应编译器的目录(armcc的请设置到Keil的目录)
修改完成后，请打开命令行窗口，先设置上scons的命令出处：(假设python安装于C:根目录下)
set PATH=c:\Python25\Scripts;%PATH%
进入RT-Thread/STM3210的目录(假设RT- Thread目录放在h:根目录下)
cd h:\bsp\stm3210
然后执行
scons 有的时候真是感叹scons的强大，强大到还不知道如何使用其内部的特殊功能。例如，scons本身是携带分析代码的功能的，最具意义的当然是它分析 C/C++头文件预处理的功能。通过这个预处理分析，能够获知哪些宏已经定义了哪些宏未定义。推广到RT-Thread之rtconfig.h，就能够自动获得RT-Thread的组件使能情况了，至于如何在构建脚本中获得，下回待续吧。。。
接上篇。有的时候，几乎可以认为编译是最耗时的一项工作，特别是接触到大型的工程以后，想象一下，当一个系统从头到尾需要编译一个下午时，调试应该如何进行。scons提供了一个非常简洁的选项，-j，就例如GNU Make中的-j一个意思，它能够同时启动多个编译任务，在多核芯片上也就能够并行的同时编译。只是，GNU Make通常不怎么管用，而scons的非常好用。
RT-Thread的构建系统同样也支持ARM RealView Compiler的，和前面相同，只需要修改下rtconfig.py文件，定义下CC和EXEC_PATH即可。不过用命令行的缺点也是*有的*，那就是下载调试并不如IDE中的方便，甚至可以说*没办法做到*。但办法总是依靠人去想的：
1. 在Keil MDK中新建立一个空工程，设备当然选择你对应的设备了，本例中的STM32F103ZE
2. 更改工程选项中，目标文件为rtthread-stm32 (命令行版本默认采用rtthread-stm32.axf/elf)，并且生成的位置位于bsp\stm3210目录下。
3. 根据使用的仿真器情况选择工程的调试方式、烧写方式
4. 烧写 & 调试。这步只需要点击Keil MDK的工具栏即可，！！千万不要去点编译！！
好了，一切就绪，可以直接调试代码了。
小提示：
命令行版本生成的目标文件后缀名可以在rtconfig.py中修改TARGET_EXT变量进行更改。而当使用GCC来进行编译时，也能够使用axf做为后缀扩展名。使用axf最大的好处是，能够获得Keil MDK烧写&调试的支持。 哈哈，顶一下，沙发 楼主干得不错，OS要有个好的开发环境，对RTT的普及大有好处啊，改天我也学学。
我也很烦keil工具不允许工程中有同名文件，甚至C和汇编文件之间都不能同名。
keil自作主张地把所有.o文件放在同一个目录，且不能设置，是产生问题的根本原因。 顶一下！ 今天试了下用SCONS编译,结果出现如下错误提示
AttributeError: 'module' object has no attribute 'RT_USING_DFS_ELMFAT':
代码已经更新到最新的SVN版本了。 SCONS版本是1.2.0，Python版本是2.6.4 这个是svn最新版本的，所以有这个问题
可以在rtconfig.py中定义RT_USING_DFS_ELMFAT=False，然后就可以编译通过了
因为最新的代码已经包含了ELM Chan's FatFs，但相应的配置还未更新 建议楼主用cmake，比较简单好用，自动生成makefile 比sons安装起来简单，在win下面有gui配置界面 cmake固然好，实际上使用scons，更看重它的python脚本功能。有了python脚本，能够自定义非常非常多的功能，这个在以后应该会有体现，最重要的一点是根据rtconfig.h自动判断哪些组件不需要，不应该参加编译。 楼主可能对python比较熟不觉得，对于新手来讲，cmake要容易入手多了，scons你的要花不少功夫去training
很多开源大项目都用cmake，功能上应该不会比scons弱 用scons应该也比较容易上手，我以前也没用过，看了相关介绍十分钟内安装完软件，然后就开始编译，正常运行了。
个人觉得scons还是比较容易上手的，对于一般使用，也不需要了解python,有Makefile基础的同学应该更没有问题了。 楼主，注意到你这个很长时间了，很佩服楼主你的代码组织能力。我用的rtems就是采用automake组织的。有时候也觉得有些复杂，可能是我对makefile理解还很浅显。但是因为工作时间的关系，也不可能太深入。希望有时间能移植你这个系统。不知道这个版权是怎么样的，是GPL吗？ 相关版权问题见这个贴
http://www.ourdev.cn/bbs/bbs_content.jsp?bbs_sn=3868507&bbs_page_no=1&bbs_id=3066 回复【11楼】gaiwang42
楼主可能对python比较熟不觉得，对于新手来讲，cmake要容易入手多了，scons你的要花不少功夫去training
很多开源大项目都用cmake，功能上应该不会比scons弱
-----------------------------------------------------------------------
主要还是看好它对python的融合能力，今天刚提交的补丁，mini2440分支(以后会逐渐向stm3210、lm3s分支推广)：
RT-Thread是依赖于rtconfig.h来配置系统的，通过它来定义是否使用外围的一些组件，内核的参数等。
以往总是有一个头大的事情，rtconfig.h修改了，还得想法更改Makefile的配置，让它编译或不编译相应的组件(当然另外一种形式是，把各种组件制作成库的形式)。所以在RT-Thread 0.2.4版本的时候，虽然依赖于python来生成配置文件(采用Makefile来组织)，其配置文件不得不生成两份，一个是rtconfig.h，给程序代码使用；一个是config.mk，给Makefile使用。
而现在采用scons就方便多了，当修改了rtconfig.h头文件时，可以自动分析其中组件相关定义而决定是否编译或不编译组件。
在很早前就知道scons有这个功能的，只是今天晚上才把相应脚本写好。 似乎有太多的人对RT-Thread使用scons不能了解其原因，揭揭内幕吧，不过揭出来不知道有多少人能够接受：
最主要原因，scons是使用python脚本的，即在scons中能够方便的调用python脚本。
然后，RT-Thread在内建一个开发环境，不会是eclipse那种复杂的环境，因为总觉得那个东西简直是把用户的机器当廉价面包，慢，慢！
再然后，这个开发环境是商业化的产品，即这个需要由用户自行购买。scons的两类文件分别对应：
- SConscript，项目工程文件，仅包括编译的文件名、编译时的参数
- SConstruct，工作空间文件(即它能够包含一个或多个SConscript文件)
所以最终，所有和scons相关的都能够通过UI来实现，不再需要自行手动的添加。
一个项目要想活下去，割舍了一方面(例如设备上的一些东西基本都完全免费)，那么另外一方面得争取到一些，所以希望在其他方面，RT-Thread能够养活自己。 目前还只习惯用make file管理代码，大小工程管理都还是比较容易。 一使用scons就喜欢上了，他比gnu make使用方便多了。就是安装麻烦，还要搞python。
页:
[1]