ant - ant + cpptasks vs.scons vs.make

Question

我正在研究scons，我只想确保在将大量脑细胞投入到完全不同的事物之前，我知道替代方案是什么。我过去一直在使用GNU make，但从未对此感到特别满意。

特别是:为什么Ant不经常在C / C++项目中使用？ (鉴于存在ant cpptasks)我读了几篇文章说(显然)Ant更面向Java，但是这样做的缺点是什么？为什么scons要比make好得多？

我正在与TI DSP的交叉编译器合作，通常项目中有20-50个cpp文件。似乎构建管理中最困难的部分是自动依赖性检查。其他所有内容都只是映射文件列表以及一组编译器选项。

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

Answer 1

对于交叉编译，我认为您的最佳选择是CMake或Autotools。特别是如果您可以针对多种体系结构/平台编译代码。我通常在本机上编译我的代码的子集，以进行单元测试，并将其全部用于目标平台。 CMake可以很好地处理此问题，因为它使您可以指定交叉编译的库所在的位置。因此，与其在/ usr / lib中搜索交叉编译的libpng，不如告诉它在/ opt / arm-eabi-gcc /中或在构建计算机上安装了工具链库的任何位置。您可以为不同的变体创建多个构建目录，并使用make手动编译每个变体，或者使用绞死了的手动递归make来触发批量生产。

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

SCons更好，但是交叉编译并不是它的优势。它也不是像CMake或Autotools这样的“构建系统”，它只是一个构建工具。就像在他们的维基it is pretty much "Make in Python"上说的那样。不过，它确实内置了对依赖项的处理，这意味着您不必使用“gcc -MM -MD”或其他任何东西，就可以将自己的内容滚动到那里，因此，这比Make更具优势。 SCons还支持检测已安装的第三方库，但是通常这样做的方式会增加您的构建时间。与其他系统不同，SCons每次运行都会运行检查阶段，尽管大多数结果都已缓存。 SCons还因其构建时间长而臭名昭著，尽管对于50个文件而言这并不是问题。 SCons中不存在交叉编译支持-您必须滚动自己的as discussed on this thread on the mailing list。通常，您将构建强制为类似于Unix平台，然后覆盖C编译器的名称。构建多个变体或将构建目录与源目录分离会充满陷阱，这使得如果您交叉和本地编译代码，它就不太合适。

CMake和Autotools很好地解决了依赖性问题，并且autotools的交叉编译支持已经成熟。 CMake从2008年4月发布的2.6.0版本开始进行交叉编译。您可以免费获得这些功能，以及打包和运行单元测试(“进行检查”或类似目标)之类的其他功能。这两个工具的缺点是它们需要引导。如果是CMake，则需要安装CMake二进制文件才能创建Makefile或Visual Studio解决方案文件。就Autotools而言，它稍微复杂一点，因为并不是每个编译该软件的人都需要automake和autoconf安装，只有那些需要更改构建系统的人(添加新文件才被视为更改构建系统)。从概念上讲，这两个阶段的引导过程(configure.ac->配置，配置+ Makefile.in-> Makefile)有点棘手。

编辑:交叉编译在构建系统中尤其令人头疼，原因是它增加了程序和库的自动检测的复杂性。 SCons不会处理此问题，而是由您自行解决。 Ant 类似地什么也不做。 Autoconf在autotools情况下可以解决此问题，但是在配置时可能需要在命令行上提供“--with-libfoobar = / some / path”，或者在链接阶段尝试使用/ usr / lib时会遇到断开的链接。 CMake的方法在工具链文件中显得有些繁琐，但这意味着您不必指定所有工具和库(CC，CXX，RANLIB，-with-ibfoo =等)，因为标准约定。从理论上讲，您可以在多个项目中重复使用适当制作的CMake工具链文件来交叉编译它们。实际上，CMake的普及程度不足以使您对普通的黑客方便，尽管在创建多个专有项目时它可能很有用。