ant+cpptasks 与 scons 与 make

我正在调查scons http://www.scons.org/我只是想确保在我将大量脑细胞投入到完全不同的事物之前我知道替代方案是什么。我过去一直在使用 GNU make，但从来没有对它感到特别满意。

特别是：为什么 Ant 没有更频繁地用于 C / C++ 项目？ （假设有ant cpp任务 http://ant-contrib.sourceforge.net/cpptasks/index.html）我读过一些文章，说 Ant 更面向 Java（显然），但是这样做有什么缺点呢？为什么 scons 比 make 好得多？

我正在使用 TI DSP 的交叉编译器，通常一个项目中有 20-50 个 cpp 文件。构建管理中的困难部分似乎是自动依赖性检查。其他一切只是将文件列表与编译器选项集映射在一起。

edit:为什么交叉编译会改变什么？它是一个编译器，其运行方式与 gcc 的运行方式相同，只是它生成的目标文件/可执行文件无法在我的 PC 上运行。

对于交叉编译，我认为你最好的选择是CMake http://www.cmake.org/ or 自动工具 http://sources.redhat.com/autobook/。特别是如果您可以为多个架构/平台编译代码。我通常在本机上编译代码的子集以进行单元测试，并为目标平台编译所有代码。 CMake 处理这个问题特别好，因为它允许您指定交叉编译库所在的位置。因此，与其在 /usr/lib 中搜索交叉编译的 libpng，不如在 /opt/arm-eabi-gcc/ 或构建计算机上安装了工具链库的任何位置进行查找。您可以为不同的变体创建多个构建目录，并使用 make 手动编译每个变体，或者使用脑残的手动递归 make 来触发批次。

Ant 的缺点是它基本上与普通 Make 一样好或一样坏，还有一个缺点是您使用的东西对于 C 或 C++ 来说并不是特别主流。您必须处理自己的所有依赖项 - 包括内部依赖项，例如 C 文件到头文件到库或可执行文件，以及外部依赖项，例如必须与第 3 方库链接。另外，我认为 Ant C 任务并没有真正维护那么多。我见过的每个使用 Ant for C 的人都提倡使用 exec 任务调用 GCC。

SCons 更好，但交叉编译不是它的强项。它也不是像 CMake 或 Autotools 那样的“构建系统”，它只是一个构建工具。正如他们的维基上所说，这几乎是“用 Python 制作” http://www.scons.org/wiki/FrequentlyAskedQuestions#head-00ce208eece451fe9879c6f8dd1c45b56f4c76d1。不过，它确实内置了对依赖项的处理，这意味着您不必使用“gcc -MM -MD”或其他什么来自行构建依赖项，因此这比 Make 有优势。 SCons 还支持检测已安装的第 3 方库，但通常的完成方式会增加很多构建时间。与其他系统不同，SCons 在每次运行时都会运行检查阶段，尽管大多数结果都会被缓存。 SCons 还因其构建时间长而臭名昭著，尽管对于 50 个文件来说这不是问题。 SCons 中不存在交叉编译支持 - 你必须自己推出正如邮件列表中该主题所讨论的 http://thread.gmane.org/gmane.comp.programming.tools.scons.user/21036。通常，您会强制构建像 Unix 平台一样，然后覆盖 C 编译器的名称。构建多个变体或将构建目录与源目录分开充满了陷阱，这使得它不太适合交叉编译和本机编译代码。

CMake和Autotools很好地解决了依赖问题，并且autotools的交叉编译支持也很成熟。 CMake 自 2008 年 4 月发布的 2.6.0 版起就开始进行交叉编译。您可以免费获得这些功能，以及打包和运行单元测试（“make check”或类似目标）等其他功能。这两种工具的缺点是它们需要引导。对于 CMake，您需要安装 CMake 二进制文件才能创建 Makefile 或 Visual Studio 解决方案文件。对于 Autotools，情况稍微复杂一些，因为并不是每个编译软件的人都需要安装 automake 和 autoconf，只有那些需要更改构建系统的人才需要安装（添加新文件算作更改构建系统）。 2 阶段引导（configure.ac -> configure、configure + Makefile.in -> Makefile）在概念上有点难以理解。

对于编辑：交叉编译在构建系统中是一个额外令人头痛的问题，因为它增加了程序和库的自动检测的复杂性。 SCons 不处理这个问题，它让你自己解决。 Ant同样什么也不做。 Autoconf 在 autotools 情况下处理这个问题，但是当您配置时，您可能必须在命令行上提供“--with-libfoobar=/some/path”，或者在链接阶段尝试使用 /usr/lib 时面临损坏的链接。 CMake 的方法对于工具链文件来说有点重，但这意味着您不必指定所有工具和库（CC、CXX、RANLIB、--with-ibfoo= 等），因为它们是从标准约定。理论上，您可以在多个项目中重复使用适当制作的 CMake 工具链文件来交叉编译它们。在实践中，CMake 的普及程度还不足以让普通黑客感到方便，但如果您要创建多个专有项目，它可能会很有用。