1222

全部学习汇总： GitHub - GreyZhang/g_SCons: A new member in my toolbox, looking forward to replacing make tool later.

我觉得SCons的应用手册的顺序编排还是可以的，至少最前面的这部分编排是不错的。非常有助于一个了解过Makefile的人去做转行的学习。前面实现了简单的单文件的编译，这一次接下来至少先尝试实现一下单目录多文件的编译了。在这次尝试的过程中，暂且也忽略掉文件依赖的概念。

为了能够实现上面的例子，首先创建几个代码文件。为了能够看看最终编译的效果，我在file1.c和file2.c中放了一个pritnf，打印一下提示信息。然后，在prog.c的main函数中调用。

之后，采用上面的配置文件信息进行测试的效果：

看得出来，构建构成。这里生成了一个叫做prog的可执行文件，为什么叫这个名字呢？文档中做了解释，如果这个可执行文件的名字没有给出来具体的名称，那么可执行程序的名称由文件列表中的第一个文件名称决定。

同事，对于多文件（暂时考虑单目录多文件的情况）的处理方法也给了说明，即创建一个列表，每一个文件都是列表中的一个字符串元素。

这样的处理采用python来处理很容易，哪怕是SConstruct的文件中支持的Python特性不多，通过脚本来更新这个配置文件都是容易实现的。

这是指定可执行文件名称的方法，需要在Program的builder method中增加一个参数。按照上面的方式修改之后的测试效果：

能够看得出来，可执行文件的名称被指定成功了。

这里又给出了一个使用通配符来实现的按照文件类别来处理的方法，这样的方法在Makefile中也是有的。真是没有，其实通过python脚本来辅助生成其他的信息也是很容易的。

这是采用通配符的方式实现的一个测试效果。

从这部分的讲解看，SConstruct中的部分python支持处理还是可以的。自然，使用的时候得符合具体的使用规则。不过，类似列表的append处理或许时候不奏效？这一点从某些角度考虑是可以理解的，比如之前就已经看到了这个SConstruct中的代码执行并不像python脚本一样有着严格的执行顺序。不然，类似文件在列表中的追加或许一个append *** 作就可以了。

Split的应用可以让配置文件中的builder method的部分看上去更加简洁。不过，从自动生成信息的角度来说的话，没有看出什么特别的优势。只要是批处理容易实现，直接用脚本构建SConstruct的时候可读性，尤其是文件列表的可读性就不是那么重要了。当然，如果SConstruct是百分百的手工维护，这样的精简风格还是更有优势的。

这里的参数用法相比前面的表述方式更有可读性上的提高，尤其是对于初步接触的人来说更有优势。然而，这个地方一共就有2个参数的时候，在熟练之后这种可读性的优势也就微乎其微了。

综合看来，在整体的可读性以及维护性上，相比老牌的Makefile方案scons的确还是有一点优势的。但是接下来的尝试才具有真正的工程管理的意义，至少我得能够用这个优雅地处理各种文件文件的依赖关系以及复杂的文件目录结构才能够让这个工具具备真正的生产力加速的效果。