我正在了解 scons，在我投入大量时间学习之前，我想确保了解一下其他选择。过去我一直使用GNU make，但对它并不是太满意。
尤其是：为什么在C / C ++项目中不经常使用Ant呢？（考虑到有Ant cpptasks）我读了一些帖子，说Ant更偏向于Java（显然），但这样做的缺点是什么？为什么scons比make好得多？
我正在使用TI DSP的交叉编译器，通常一个项目中有20-50个cpp文件。构建管理中困难的部分似乎是自动依赖检查。其他所有操作只需要将文件列表与编译器选项集映射起来即可。
编辑：那么为什么跨编译会改变任何事情呢？它是以与gcc相同的方式运行的编译器，只是它生成的目标文件/可执行文件不能在我的PC上运行。
对于编辑：交叉编译是构建系统中的额外麻烦，因为它增加了程序和库的自动检测的复杂性。SCons不处理这个问题，它把这个问题留给你去解决。Ant同样也没有处理。在autotools情况下，Autoconf处理这个问题，但是当你配置时，你可能需要在命令行上提供“-with-libfoobar=/some/path”，否则在链接阶段尝试使用/usr/lib时会出现链接错误。CMake的方法稍微重量级一些，需要使用工具链文件，但这意味着你不必指定所有的工具和库（CC、CXX、RANLIB、--with-ibfoo=等），因为它们是从标准约定中找到的。理论上，你可以在多个项目中重用一个精心制作的CMake工具链文件来进行交叉编译。实际上，CMake并不普及，对于普通黑客来说并不方便，但如果你正在创建多个专有项目，则可能很有用。
在过去的五年中，我一直在从事一个项目，该项目使用ant进行x86和arm构建。我们为了生产通用编译器而调整了cpptasks，只需传入前缀（例如arm-gum-linux-gnueabi-），然后将其添加到实际工具（如g++或ar）之前即可。没有前缀意味着您会得到开发平台的构建工具。交叉编译的工具链在其构建工具二进制文件中具有这些前缀。选择Ant而不是基于Make的任何东西几乎全部原因是cpptasks能够执行增量构建以及保持autoconf正常运行所必须发生的混乱。我们能够支持几乎任何源文件的范例，特别是用于库集的文件夹树结构中的文件可以被创建/重命名/删除，而无需对构建文件进行任何编辑。一个小缺点是链接文件会以一种导致不必要的重建的方式更新属性。
<target name="lib.cvp">
<fetch.and.log.version
svnvers.target="common/cvp"
svnvers.property="libcvp.version"/>
<cc objdir="${obj.dir}/common/cvp"
commandPrefix="${command.prefix}"
compilerName="${compiler.name}"
outfile="${lib.dir}/cvp" outtype="static">
<compiler extends="base.compiler"/>
<compilerarg
value="-D__CVP_LIB_BUILD_VERSION__="${libcvp.version}""/>
<compilerarg
value="-D__BUILD_NOTES__="${libcvp.toolversion}""/>
<compilerarg if="is.x86" value="-DARCH_X86"/>
<linker extends="base.linker"/>
<includepath refid="common.inc"/>
<fileset dir="${project.home}/common/cvp">
<include name="*.c"/>
<include name="*.cpp"/>
</fileset>
</cc>
</target>
Ant拥有非常Java-heavy的用户群（出于自然原因）。事实上，大多数非Java开发人员并不知道Ant在更广泛的环境中可以非常有用。因此，如果您使用Ant构建C/C++代码，您将比使用具有更大用户群的系统（如CMake或SCons）更加独立。
就个人而言，我非常喜欢CMake，主要是因为它是唯一一个可以生成真正Visual Studio项目的构建系统。SCons也可以，但它们只是对SCons进行外部调用，而CMake生成的项目使用了Visual Studio自己的构建引擎。如果您与习惯于使用Visual Studio的人一起工作，这非常有用。
我不确定是否应该称CMake对交叉编译的支持“成熟”，因为它仍然很年轻。但是，CMake的开发人员非常认真对待它，所以我毫不犹豫地尝试了它。