ant+cpptasks vs. scons vs. make [英] ant+cpptasks vs. scons vs. make

问题描述

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

I'm looking into scons and I just want to make sure I know what the alternatives are, before I invest a chunk of brain cells into something completely different. I've been using GNU make in the past but have never been particularly happy with it.

特别是:为什么 Ant 没有更频繁地用于 C/C++ 项目?(鉴于有 ant cpptasks)我读了一些帖子说 Ant 是更面向 Java(显然)，但是这样做的缺点是什么?为什么 scons 比 make 好得多?

Particularly: why isn't Ant used more often with C / C++ projects? (given that there's ant cpptasks) I read a few posts that say that Ant is more oriented around Java (obviously), but what's the drawback to doing so? And why is scons so much better than make?

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

I am working with a cross-compiler for TI DSPs, typically there are 20-50 cpp files in a project. It would seem like the hard part in build management is automatic dependency checking. Everything else is just mapping lists of files together with sets of compiler options.

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

edit: and why does cross-compilation change anything? it's a compiler that runs the same way gcc runs, just that it produces object files / executables that won't run on my PC.

推荐答案

对于交叉编译，我认为你最好的选择是 CMake 或 Autotools.特别是如果您可以为多个架构/平台编译代码.我通常在本机机器上编译我的代码的一个子集以进行单元测试，并将所有代码都编译到目标平台上.CMake 处理得特别好，因为它允许您指定交叉编译的库所在的位置.因此，与其在/usr/lib 中搜索交叉编译的 libpng，不如在/opt/arm-eabi-gcc/或任何安装在构建机器上的工具链库中查找.您可以为不同的变体创建多个构建目录，并使用 make 手动编译每个变体，或者使用脑残的手卷递归 make 触发批量.

For cross compiling I think your best choices are either CMake or Autotools. Especially if you can compile your code for multiple architectures/platforms. I typically compile a subset of my code on the native machine for unit testing purposes and all of it for the target platform. CMake handles this especially well, as it lets you specify where the cross compiled libraries live. So rather than searching for the cross compiled libpng in /usr/lib, it can be told to look in /opt/arm-eabi-gcc/ or wherever you have the tool chain libraries installed on your build machine. You can create multiple build directories for the different variants and manually compile each variant with make, or trigger the lot with a braindead hand-rolled recursive make.

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

Ant has the drawback that it is basically as good or as bad as vanilla Make, with the added disadvantage that you are using something that is not particularly mainstream for C or C++. You have to deal with all your own dependencies - both the internal ones, such as C file to header file to library or executable, and also external dependencies such as having to link with 3rd party libraries. Plus I don't think the Ant C tasks are really maintained that much. Everyone I've seen that uses Ant for C advocates calling out to GCC with exec tasks.

SCons 更好，但交叉编译不是它的强项.它也不是像 CMake 或 Autotools 这样的构建系统"，它只是一个构建工具.正如在他们的 wiki 上所说，几乎是用 Python 制作".不过，它确实内置了对依赖项的处理，这意味着您不必使用gcc -MM -MD"或其他任何东西在那里滚动，因此这比 Make 有优势.SCons 还支持检测已安装的 3rd 方库，但通常这样做的方式会增加您的构建时间.与其他系统不同，SCons 每次运行时都会运行检查阶段，尽管大多数结果都被缓存了.SCons 也因其漫长的构建时间而臭名昭著，尽管对于 50 个文件来说这不是问题.SCons 中的交叉编译支持是不存在的 - 你必须推出自己的 在邮件列表中的这个线程中讨论过.通常，您强制构建类似于 Unix 平台，然后覆盖 C 编译器的名称.构建多个变体或将构建目录与源目录分开充满了陷阱，这使得它不太适合交叉和本地编译代码.

SCons is better, but cross compiling is not its strong point. It is not a "build system" like CMake or Autotools either, it is only a build tool. As it says on their wiki, it is pretty much "Make in Python". It does have built in handling for dependencies though, meaning you don't have to roll your own there with "gcc -MM -MD" or whatever, so that is an advantage over Make. SCons also has support for detecting 3rd party libraries that are installed, but the way it is usually done can add a lot to your build time. Unlike other systems, SCons runs the checking stage every time you run it, though most results are cached. SCons is also infamous for its long build times, though for 50 files that would not be an issue. Cross compilation support in SCons is non-existent - you have to roll your own as discussed on this thread on the mailing list. Typically you force the build to be like a Unix platform, then override the name of the C compiler. Building multiple variants or separating the build directory from the source directory is full of gotchas, which makes it less suitable if you cross and natively-compile your code.

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)在概念上有点难以理解.

CMake and Autotools have the dependency problems figured out quite well, and autotools' cross compilation support is mature. CMake has had cross compilation since version 2.6.0, which was released in April 2008. You get those features for free, plus others like packaging and running unit tests ("make check" or similar targets). The downside to both of these tools is they require bootstrapping. In the case of CMake, you need to have the CMake binary installed to create the Makefiles or Visual Studio solution files. In the case of Autotools it is slightly more complicated because not everybody who compiles the software would need automake and autoconf installed, only those that need to change the build system (adding new files counts as changing the build system). The 2 stage bootstrapping (configure.ac -> configure, configure + Makefile.in -> Makefile) is conceptually a bit trickier to understand.

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

For the edit: Cross compiling is an extra headache in build systems for the reason that it adds complexity to the auto-detection of programs and libraries. SCons doesn't deal with this problem, it leaves that up to you to sort out. Ant similarly does nothing. Autoconf handles this in the autotools case, but you may have to provide "--with-libfoobar=/some/path" on the command line when you configure or face broken linking when it tries to use /usr/lib in the link phase. CMake's approach is a little more heavywieght with the toolchain file, but it means you don't have to specify all of you tools and libraries (CC, CXX, RANLIB, --with-ibfoo=, etc) as they are figured out from a standard convention. In theory you can reuse a suitably crafted CMake toolchain file in multiple projects to cross compile them. In practice CMake is not widespread enough to make this convenient for your average hacker, though it may be useful if you are creating multiple proprietary projects.

这篇关于ant+cpptasks vs. scons vs. make的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！