标签 Unix 下的文章

发掘Scons

发现或者说知道SCons是缘于Google的comp.lang.c group上的一则名为"Best Build Tool for large C projects "的帖子,帖子的作者列出了11条他认为"Best Build Tool"应该具备的特点,并欲找到这样的Build Tool。在该帖子的回复中,有人提到了Scons,说来惭愧,这是我第一次听说到有这样一个工具。一直在Unix下编写C程序,习惯了Make,也对Make的复杂度和较为陡峭的学习曲线有所了解,曾经尝试使用AutoconfAutomake,但是都因上手困难而放弃。自己心底也一直想找到一个更简单一些的但又不失功能的适合C的Build Tool,Scons是否能满足的需要的呢?好奇心驱使着我去发掘一下Scons。

工具的进化一直在持续着。高手能把Make玩弄于股掌之中,但是大多数人水平还是一般的,在经历了"Make hell"后他们要寻求更简单、更人性的工具,这也是工具进化的动力之一。Scons是用Python实现的一款跨平台的开源Build Tool,用Python实现意味着Scons比Make所使用的类Shell语言更贴近于自然语言,更易于理解和控制;用Python实现的另一个好处也是Make所不具备的就是很好的跨平台能力,一次编写Build脚本,在多种平台上无需修改即可运行无误,特别是从Unix->Windows这样的移植,如果使用Make则势必要修改。

先简单说说Scons的安装,要运行Scons势必你的机器上要有Python,虽然Python 3.0已经Release,但目前主流Python开源项目仍然在用2.x版本。我的机器上安装的就是Python 2.5。下载Scon-1.10稳定版,unzip,进入unzip后的目录,执行安装命令:python setup.py install即可。Scons会被安装到默认目录下,如果你想指定安装目标目录的话,可以使用–prefix=YOUR_INSTALL_DIR参数。

按照惯例,我们先来一个"Hello, World!"的例子,在你的测试目录下,编写一个HelloWorld.c
/* HelloWorld.c */
#include <stdio.h>
 
int main(int argc, char* argv[])
{
   printf("Hello, world!\n");
   return 0;
}
在同一级目录下,建立一个新文件SConstruct,编辑该文件,输入内容:
Program(‘HelloWorld.c’)
在命令行下执行scons,一个名为HelloWorld.exe的可执行文件(在Unix下可执行文件为HelloWorld)被编译链接成功。第一次上手成功会给使用者带来莫大的成就感,提高该使用者继续发掘该工具的可能性。

SConstruct是个什么文件?SConstruct之于Scons就好比Makefile之于Make;它是Scons的输入,SConstruct中的内容采用的是Python的语法,而Python的语法比较简单,这样很容易被接受,而Program则只是一个方法调用。Program(‘HelloWorld.c’)意味着告诉Scons我要将HelloWorld.c编译成一个名为‘HelloWorld.exe’的可执行文件,当然了Scons会自动分析HelloWorld.c,自动得出目标程序名字。

我们日常工作构建代码的类型不外乎如下几种:简单一点的包括编译object文件、构建静态库、构建动态链接库和构建可执行程序;复杂的则是要对一个拥有众多目录和几十万、上百万行代码的项目进行整体体系构建,而复杂的构建也是由一系列的简单构建组合而成的,我们先说说简单类构建。

HelloWorld例子只是一个最简单的由单个源文件构建程序的例子,现实中我们构建可执行程序可能依赖的不止是一个文件,可能还有头文件或链接其他第三方库;下面这个SConstruct文件中的语句就是一个稍微复杂些的例子:
Program(target = ‘test’, source = ['main.c', 'file1.c', 'file2.c'], LIBS = ['lib1', 'lib2'], LIBPATH = ['lib1/lib', 'lib2/lib'], CPPPATH = ['include', '/lib1/include', 'lib2/include'], CCFLAGS=’-D_DEBUG’)

这个例子中具备我们常用的诸多元素,这些参数中:’test’是构建后的程序名,source是一个源文件数组,LIBPATH则是要链接库的目录数组,LIBS是要链接的具体的库文件的名字。CPPPATH则是-I的替代品,是头文件所在目录的数组,CCFLAGS则是负责传递编译器的编译选项参数。

通过这些Keyword Arguments,Scons可以在用户和编译器之间传递信息,并控制编译器完成构建。同样的,编译目标文件,构建静态库、动态库可以由下面的一些builder来完成。

Library(‘foo’, ['f1.c', 'f2.c', 'f3.c'])   #生成名为foo的静态库,在Windows上是foo.lib,在unix上为libfoo.a
<=> StaticLibrary(‘foo’, ['f1.c', 'f2.c', 'f3.c']) #生成名为foo的静态库,在Windows上是foo.lib,在unix上为libfoo.a
SharedLibrary(‘foo’, ['f1.c', 'f2.c', 'f3.c']) #生成名为foo的动态库,在Windows上是foo.dll,在unix上为libfoo.so
Object(‘add.c’) #生成名为add的目标文件,在Windows上是add.obj,在unix上为add.o

Scons没有明显的依赖定义,Scons会为我们自动扫描依赖。我们只需告诉它构建出一个目标需要什么即可。Scons检查依赖关系中的文件变化的方法,除了通过时间戳,还可以通过MD5来判别,你可以通过设置Env来决定使用哪个。另外更强大的是你也可以自己编写文件更新检查方法放到SConstruct中被Scons调用,这些都是高级一些的功能,这里不细说,详情可参见Scons的doc

前面说过,实际项目的代码往往不可能都放到单一目录下,而是按照一定规则被放到有层次结构的目录体系中,Scons提供一个叫SConscript的方法支持这种情形。下面用一个复杂一些的例子来说明这种情形。
我们假设有一项目的目录结构如下:
- Test_Proj
    - SConstruct
    - include
        - base.h
        - module1.h
        - module2.h
    - main
        - main.c
    - module1
        - module1.c
    - module2
        - module2.c
    - xlib
        - include
            - xlib_base.h
            - add.h
            - sub.h
        - add
            - add.c
        - sub
            - sub.c
        - lib
针对该Proj,我们要将整个工程构建为一个可执行程序。简单分析一下,这个程序依赖xlib下的两个库

关于宏定义切换以及屏蔽的例子

assert是大家常用的宏,它的用法相信大家都有所了解。P.J Plauger的"The C Standard Library"一书中提到在源代码中切换assert宏定义的方法:
/* turn assertion on */
#undef NDEBUG
#include

/* turn assertions off */
#define NDEBUG
#include

我顺手写了一个例子如下:
/* testmacro1.c */
#define NDEBUG
#include

int main() {

        assert(0); // => ((void)0);

#undef NDEBUG
        #include
        assert(0); // => (void)((0) || (__assert("0", "testmacro.c", 10), 0));
}
测试结果正如P.J Plauger的说明。但仔细看来似乎有些疑惑:总觉得第二个assert也应该展开成((void)0)才对啊。由于NDEBUG被定义,在第一次assert.h展开时,assert就被替换成了((void)0),而后虽然NDEBUG被disable了,但此时由于assert.h的header file guard保护,assert的新定义并没有被重新loaded & evaluated,所以assert似乎依然应该被展开为((void)0),但执行结果却不是。

我自己写了一个程序测试了一下:
/* testmacro1.h */
#ifndef TEST_MACRO1_H
#define TEST_MACRO1_H

#ifdef X_DEBUG
#define x_debug(expr)   ((void)0)
#else
#define x_debug(expr)   #expr
#endif
#endif

/* testmacro1.c */
#define X_DEBUG
#include "testmacro1.h"

int main() {
        x_debug(0); // => ((void)0);

#undef X_DEBUG
        #include "testmacro1.h"
        x_debug(0); // => ((void)0)
}
果不其然,结果正如我所猜测的:
#undef X_DEBUG
#include "testmacro1.h"
并没有改变x_debug的定义,那么第一个例子到底是怎么回事呢?

其实这是C标准库设计所致,打开你所在系统的assert.h标准文件,我在sun solairs 9上是这样的:
#ifndef _ASSERT_H
#define _ASSERT_H
… …
#endif

#undef  assert
#ifdef  NDEBUG
#define assert(EX) ((void)0)
#else
#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0))
#endif  /* NDEBUG */

哈哈,这下子看清楚了,原来assert的定义根本不在Header File Guards的保护下,怪不得我思前想后都对不上呢:),因为没有File Guards的保护。使头文件中的宏有机会被重新loaded&envaluated。

下面例子中的第三个assert屏蔽掉了标准库中的assert实现:
/* testmacro3.c */
#define NDEBUG
#include

int main() {

        assert(0); // => ((void)0);

#undef NDEBUG
        #include
        assert(0); // => (void)((0) || (__assert("0", "testmacro3.c", 10), 0));

#define assert(exp) (#exp)
        assert(x==0); // => ("x==0");
}
这种屏蔽很简单,就不多说了,自己看吧。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats