[投票] RT-Thread应采用何种开发环境？

发布于 2009-07-01 19:38:51 浏览：5260 订阅该版

4 个回答

aozima 2009-07-01

调网络不抓包，调I2C等时序不上逻辑分析仪，就像电工不用万用表！多用整理的好的文字，比截图更省流量，还能在整理过程中思考。

bernard 2009-07-01

这家伙很懒，什么也没写！

bernard 2009-07-05

这家伙很懒，什么也没写！

转一份关于scons的文章：
----------------------------------------
呵呵，看来这个软件在国内接触的人确实不多。我注意BuildSystem是相当早了，最早在1999年
的时候发狠把当时的autoconf、automake手册给翻译成中文了。在相当长的一段时间之内，个人
感觉autoconf/automake/make的组合是可以满足基本需求的。所以当时还进一步翻译了GNU 软件
发行惯例。这些译文大家都可以在 [http://www.linuxforum.net/books/index.php](http://www.linuxforum.net/books/index.php) 看到。

大约在2001年吧，我开始在Linux下做嵌入式开发。此前虽然发现了一些autoconf/automake/make
的问题，但还没到痛苦的地步。因为嵌入式Linux系统，要多出交叉编译和系统生成两大块任务，
用autoconf/automake/make就开始感受到限制了。当然那时候还不知道什么其他的创建工具的存在，
所以就仿照 kernel build system 的方法，用make来做。其间也确实遭受了不少痛苦经历，呵呵。

后来在2003年终于忍无可忍，开始寻找新工具。找来找去，由于偶然或非偶然的机会，发现了scons。
用过之后就再也没改了。那时候scons的版本还比较低，不过已经相当好用了。这里列举一下区别吧：

* 对交叉编译的支持：
  autoconf/automake/make 把所有的变量名都放在一个命名空间之中，这使得我们只能用不同的变量
名来区分用于不同体系的编译宏。例如，在kernel build system里面，CC这个变量是用于编译目标
体系结构的代码的，而HOSTCC则是用于编译当前体系结构的代码的。所有其它变量都必须通过加前缀
的方式加以区分；
  scons 提供 Environment 对象，每个对象都是一个编译变量容器。所以针对不同的目标体系结构，
在scons中可以存在大量的 Environment 对象。例如像 kernel build system 那样，可以分别为目标
体系结构和当前体系结构定义两个明确区分的 Environment 对象。而不会造成任何混淆；
* 如何确定一个文件是否改变：
  make 是使用文件的timestampe来检查文件是否已经被改变了。可是这就要求当前系统具有正确的
系统时钟。这一问题在使用CVS时会更加突出一些。因为CVS会纪录提交时间，加入CVS服务器的系统
时钟超前或者落后，那么肯定会造成混乱。还有一个问题就是如果通过CVS取回以前的版本，那么它
会把这个文件的时间设置成该文件提交的时间。如果再以时间戳为准判断文件是否改变，就会出现
把改变了的文件误认为没有改变的文件的情况了。
 scons 以文件内容的校验和为标志来确认文件是否被改变。以校验和为标志可以脱离对系统时间的
依赖，当然付出的代价是速度比时间戳慢一点。不过通过获得精确的依赖性关系所节省的时间，要比
依赖关系不全而被迫使用 make clean 要短许多吧。同时scons也支持使用时间戳作为判断依据。
* 是否参考命令行的变化：
 make 在检查依赖性的时候，并不检查命令行的变化。可是命令行的变化却对目标文件的生成有着
很大的影响。例如，在命令行里面，加-g或不加-g、加-DNDEBUG或不加-DNDEBUG。
 scons 把命令行的变化考虑在内，如果命令行发生变化了，那么目标也必须重新编译。
* 是否拥有全局依赖性信息：
 autoconf/automake/make 组合，以递归的方式使用 make。但是在这样的情况下，会出现问题：
假定源代码目录结构为根目录下有： lib、src、tools 几个目录，其中均还有源代码。那么如果在
src 目录中执行 make，lib 目录中的文件即时发生了变化，也不会重新编译lib中的源代码。当然
这是由于递归方式使用make导致make没有获得完整的依赖关系造成的。具体参见：
[http://aegis.sourceforge.net/auug97.pdf](http://aegis.sourceforge.net/auug97.pdf)
 scons 则是每次都完整地运行整个buildsystem代码，以获得完整的依赖关系。它不会出现上述缺陷。
* 编程语言：
 autoconf/automake/make 组合，混杂了 m4、make、shell 等众多不同的脚本语言，没有一样是常用的。
 scons，纯python。由于python是全功能流行的强攻能语言，这使得组建编译系统的能力和便捷性大大增强。
* 跨平台：
 autoconf/automake/make 在 Windows 下，必须在mingw之类的模拟环境中运行。这是因为autoconf生成的
configure脚本使用了许多shell命令，这些都要由环境来提供。而且不同系统中的命令集合有可能不同，同一
命令的具体功能也可能不同。同时，make存在众多不同版本。为了弥补这些似是而非的区别，导致了
autoconf/automake的高度复杂性。
 scons，支持跨平台，除了python 之外没有其它依赖。在Windows下即可以在mingw中运行，又可以在普通
Windows命令行中运行。
* 复杂度：
 autoconf/automake/make 组合，必须编写 configure.ac、Makefile.am。而最终使用的
configure 脚本和
Makefile 可能长达数万行，我本人就曾被这些几万行的东西搞得天昏地暗。打开一次都折寿。
 scons，脚本相当简单。在scons内部就可以自动完成各种自动依赖性的扫描。
* 对代码生成、信息传播的支持：
 我们知道，一项信息如果只存在于一个地方是最好的。如果存在于两个地方就可能因为不一致而造成BUG。
例如说，屏幕的尺寸。但是需要信息的地方可能不止一个，这时候就需要我们把仅存在于一处的信息传播
到所有需要它的地方。这种传播可能发生在运行时，也可能发生在编译时。发生在编译时的传播适用于在
软件的特定版本中不变的常量，优点是不必在运行时付出任何代价。一般而言比较简单的这类传播是
通过宏定义实现的，但更为复杂的就会涉及到源代码的生成。
 autoconf/automake/make 只能使用shell脚本生成，不能实现过于复杂的处理
 scons 可以用python 函数实现任意复杂度的处理。例如我曾经在我的scons脚本里面，调用 subversion-python
的模块，自动把svn版本号潜入到源代码中。

上面列举的区别，有些是质的区别，有些是量的区别。但是无论如何，以较低的代价获得较好的效果，使得
我们能够把更多的注意力放到完成BuildSystem的功能上去。所以我认为即使仅仅是量变、简化也有意义。

呵呵，不过我发现长久以来似乎国内无人注意到这一软件。我想python爱好者当中总会有人感兴趣吧？
在2003年我曾经使用scons开发过一个项目。连接是：http://trac.magiclinux.org/magicinstaller/wiki/MagicInstaller
不过那时候对scons的了解还很肤浅，没能做到一条命令生成整个嵌入式目标文件系统。现在已经是piece of cake了。