1231_使用SCons实现多目录多文件且跨目录引用的编译环境搭建（linux + gcc）

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

这个例子在我看到的文档中是没有的，但是这个却是我一直想要看到的一个状态。因为，多目录、多文件、相互交叉引用的应用才算得上是一个实用工程的功能典型代表。为了能够做相应的验证，我自己创建了一个简单的工程，工程中包含了5个简单的模块。具体的目录信息如下：

一共有5个目录，10个文件。除了main模块之外，每一个目录中都包含一对儿文件，分别有一个C文件和一个头文件。其中，comm这个模块作为共用的模块会被其他的每一个模块引用。而main作为一个集中的程序模块，包含一个main函数并且调用其他所有模块的函数。这样，一个基础的示范工程就基本就绪了。另外，在根目录的位置放了SCons的配置文件。

如果要实现这样的工程的管理，按照之前的基础的知识需要完成的主要内容需要有：

1，指明工程的可执行文件的名字；

2，需要知道接下来需要处理的代码文件都是哪些；

3，为了能够让SCons找到被引用的头文件，需要指明头文件所在的目录。

如此，SConstruct的构建比较简单了。需要说明的是，CPPPATH其实只能够指明头文件的搜索目录，但是无法指明C文件的搜索目录。我觉得应该还会有一个类似的功能让我们的配置写得更加简洁。但是，目前在找到这个答案之前我采用的方法是通过相对目录的方式直接给每一个文件指明所在的目录。

如此，我的配置文件内容如下：

如此，我期望我自己的工程编译出来的可执行文件名称是test。

这是编译测试的效果，看起来还是可以的。

从前面的信息基本知道，现在默认的编译差异判断是根据MD5校验和来判断的。接下来，我改变几个文件的时间戳来试一下，是否会出现新的重新编译。

从结果看，其实是没有发生变化的。接下来，我在test.h中增加一行注释，看看接下来的效果。

为了能够有明显的对比效果，我等待一分钟后进行编译测试。

可以看得出来，有新的编译效果。但是test其实是没有更新的，这就是前面看文档的时候看到的一个节省编译效果的一个例子了。

接下来，尝试让这个行为更像make的模式。在配置文件中增加Decider('make')后测试：

可以看的出来，现在基本上是一个make的行为了。

那么如何可以确认实现一个混合模式的编译呢？其实还是可以通过注释来处理，如果修改了注释，时间戳发生了变化接下来就会去执行MD5校验和的计算。但是，目标文件不会发生变化，因此test不会更新。但是，在进行大量的文件判断处理的时候这样是有优势的变化的。

从上面的时间戳信息可以看得出与我们期待一致的结论。

这样，不仅仅是把基础的环境搭建尝试了一下，还尝试了不同的编译差分判断模式。如果习惯性考虑，直接采用make的模式应该就是不错的选择了。

最后，测试了一下并行编译的功能。也是可以直接支持使用的，而且从滚屏的速度上的确是看到了速度上的差异。编译之后的软件执行跟之前的效果也是一致的。