SCONS 使用心得分享

[dengqianyi]

楼主我做手游的，在手游开发后期，会有很多个渠道接入的需求，如果手工打包的话，在有频繁更新的情况下，研发人员要手工打多个包，会直接崩溃掉的。

在自己开发了几个python脚本后，每个脚本执行固定的功能，很快发现脚本之间的联系太少，如果要整合的话，花费时间会不少，期望能有开源的python框架可以使用。

最后找到python的scons，其本身是一个程序编译构建工具，由于是python写的，所以很容易扩展，把自动化工作当作工程的一部分，原本离散的脚本消失了，原脚本实现的功能可以当作是scons里的一个编译工具，很方便得在各个模块间共享。

比如我实现了一个对PNG图片的压缩工具，放以前得话，如果是写在一个脚本里，那对图片的存放位置就会很固定，一般要求放在一个目录下。换在SCONS里，把处理PNG的代码变成SCONS的一个编译器，对图片的存放要求就没有了，可以在SCONS扫描整个工程的时候，识别*.png，调用相应编译器处理。其他文件类型类似，可以很容易的自定义一个编译器，处理对应的文件类型。

写了2天得代码，发现自己走了一些弯路，如下：
1.scons貌似无法处理文件夹，尝试过几次，想设计一个编译器可以拷贝文件夹，但多方尝试失败，后面总结可能是因为SCONS的编译器只能针对单个文件吧，编译编译不就是对文件进行处理么？没有对文件夹处理得编译器。
2.SCONS的相应脚本，sconstruct,sconscript的SCONS相关得代码都只是‘声明’，并不是和shell一样，我们想在SCONS执行结束后做一些操作，貌似很难，只能在一般得python脚本里写。
3.因为SCONS的‘声明’的特性，所以我们在使用的时候，容易把一般python代码与SCONS混淆。

和大家分享下这几个特性，这边也想问下大家有对SCONS熟悉的不？我这边边看uerguide边写，怕是还会走不少弯路，欢迎大家也分享下SCONS的使用心得。

[clino]

还有个waf可以试试，以前看过觉得比scons好

[dengqianyi]

@clino 你用过waf?感觉如何？

[aisk]

grunt或者gulp一类的node的工具或许比较合适？至少扩展性要好一些

[zts1993]

第二次看到scons，，上一次还是组里的某个项目。

这东西和写python脚本有什么区别？

[clino]

@dengqianyi 感觉比scons更易学易用更小巧

[bigbee]

1.scons貌似无法处理文件夹：你这是对python不熟啊，处理文件夹用python代码解决不就行了？这与scons没啥关系啊，而且scons本身就是python代码
2. 还是你对python不熟悉，而且对scons也不熟悉
3. scons本身就是python代码，没啥混淆的问题存在

[dengqianyi]

@zts1993 都是python，但SCONS提供了更多功能可以使用，比如对图片压缩的批处理上，你自己写的脚本每次调用时，会对所有的原图片进行压缩一次，如果加上scons，则只会对修改过的原图片进行压缩，其他未改图片不做处理。

[dengqianyi]

@bigbee 可以调用python本身的代码对文件夹进行处理，但SCONS在执行sconstruct、sconscript时，会先全部加载一遍，然后再分别执行，如果你python的代码夹杂在其中，那么就会在scons加载sconscript时执行，流程的控制上会有2条执行线，所以我说会‘混淆’。我现在的做法是：
0.在调用scons之前再包一层,比如在build.py里调用scons
1.sconscript和sconstruct里只使用自定义编译函数对文件进行处理。
2.其他python代码如果涉及到文件处理，尽量在build.py里处理。

[dengqianyi]

@bigbee 正在熟悉scons中，感觉有很多特性我没用上，你介绍介绍呗

[dengqianyi]

@aisk 比较喜欢python这一脚本语言哈，研究的也比较多。你说的2个框架都是基于JS的，我觉得scons基于Python，扩展性上不会比js的框架差。而且sconscript写起来感觉就是在写python，没啥特殊要求。