1 构造工具的优劣

工具	易用性	正确性	性能	可伸缩性
GNU Make	差	差	优	优
Ant	良	优	良	良
SCons	优	优	良	良
CMake	良	优	优	优
Eclipse	良	优	良	差

易用性：开发人员或构造系统维护人员在使用该工具的描述语言对构造过程进行描述时，是否方便易用？
正确性：构造工具是否每次都能生成正确的可执行程序吗？还是会遗漏某些重要的依赖文件？
性能：构造工具时高效完成任务，还是让用户常常等待？
可伸缩性：对于包含成千上万个源文件的大型软件项目，构造工具能承担吗？

2 现实场景

2.1 源代码放在单个目录中

一些小型的程序才会把所有源文件都放在同一个目录中。

.
└── src
    ├── add.c
    ├── calc.c
    ├── mult.c
    ├── numbers.h
    └── sub.c

2.2 源代码在多个目录中

这是一般软件产品的常见布局。

.
└── src
    ├── calc
    │   └── calc.c
    ├── libmath
    │   ├── clock.c
    │   ├── letter.c
    │   └── numbers.c
    └── libprint
        ├── banner.c
        ├── center.c
        └── normal.c

2.3 定义新的编译工具

大型软件项目尝尝包含非标准的编译工具，因此必须有某种方法来告诉构造系统，如何使用新的工具，以及如何推测文件的所有依赖关系。

2.4 针对多个变量进行构造

大型软件产品常常需要支持多个构造变量，开发人员必须提供某种途径，来指定使用哪种构造变量进行构造。

2.5 清除构造树

当构造工具完成了构造树中所有软件的编译之后，就需要某种方法来删除所生成的所有文件，但仍保持源代码完整不变。

2.6 对不正确的构造结果进行调试

每种构造工具都必须提供某种方法来对构造过程进行跟踪，并判断编译有误的原因。