我正在研究scons,我只是想确定我知道替代方案是什么,然后我将一大块脑细胞投入完全不同的东西.我过去一直在使用GNU make,但从未对它特别满意.
特别是:为什么Ant不经常用于C/C++项目？(鉴于有蚂蚁cpptasks)我读了一些帖子,说Ant更多地围绕Java(显然),但这样做的缺点是什么？为什么scons比make好多了？
我正在使用TI DSP的交叉编译器,通常项目中有20-50个cpp文件.看起来构建管理中的难点是自动依赖性检查.其他一切只是将文件列表与一组编译器选项一起映射.
编辑:为什么交叉编译会改变什么？它是一个运行gcc运行方式的编译器,只是它生成了不能在我的PC上运行的目标文件/可执行文件.
对于交叉编译,我认为您最好的选择是CMake或Autotools.特别是如果您可以为多个体系结构/平台编译代码.我通常在本机上编译我的代码子集以进行单元测试,并为目标平台编译所有代码.CMake处理这个特别好,因为它允许您指定交叉编译库的位置.因此,不是在/ usr/lib中搜索交叉编译的libpng,而是可以告诉它查看/ opt/arm-eabi-gcc /或者在构建机器上安装了工具链库的任何地方.您可以为不同的变体创建多个构建目录,并使用make手动编译每个变体,或者使用braindead手动滚动递归make触发该批次.
Ant的缺点是它基本上和vanilla一样好或坏,还有一个缺点就是你使用的东西不是C或C++的主流.您必须处理所有自己的依赖项 - 包括内部的依赖项,例如C文件到头文件到库或可执行文件,以及外部依赖项,例如必须与第三方库链接.另外,我不认为Ant C任务确实维护得那么多.我见过的每个人都使用Ant为C提倡用户执行任务来向GCC打电话.
SCons更好,但交叉编译不是它的优点.它不是像CMake或Autotools那样的"构建系统",它只是一个构建工具.正如它在他们的维基上所说,它几乎就是"用Python制作".它确实内置了对依赖项的处理,这意味着您不必使用"gcc -MM -MD"或其他任何东西来处理它们,因此这比Make更有优势.SCons还支持检测已安装的第三方库,但通常的方式可以为您的构建时间增加很多.与其他系统不同,SCons每次运行时都会运行检查阶段,但大多数结果都是缓存的.SCons因其漫长的构建时间而臭名昭着,尽管50个文件不会成为问题.SCons中的交叉编译支持是不存在的 - 您必须按照邮件列表中此线程上的讨论自行滚动.通常,您强制构建类似于Unix平台,然后覆盖C编译器的名称.构建多个变体或将构建目录与源目录分离是充满了陷阱,如果您跨代并本机编译代码,则不太适合.
CMake和Autotools很好地解决了依赖问题,而autotools的交叉编译支持已经成熟.CMake自2008年4月发布的2.6.0版本开始进行交叉编译.您可以免费获得这些功能,还有其他功能,如打包和运行单元测试("make check"或类似目标).这两种工具的缺点是它们需要自举.对于CMake,您需要安装CMake二进制文件以创建Makefile或Visual Studio解决方案文件.在Autotools的情况下,它稍微复杂一点,因为并非每个编译软件的人都需要安装automake和autoconf,只需要更改构建系统(添加新文件就像更改构建系统一样).2阶段bootstrapping(configure.ac - > configure,configure + Makefile.in - > Makefile)在概念上有点难以理解.
对于编辑:交叉编译在构建系统中是一个额外的难题,因为它增加了程序和库的自动检测的复杂性.SCons不处理这个问题,它由你来解决.Ant同样没有任何作用.Autoconf在autotools的情况下处理这个问题,但是当你在链接阶段尝试使用/ usr/lib时配置或面对断开的链接时,你可能必须在命令行上提供"--with-libfoobar =/some/path" .CMake的方法与工具链文件相比更加重要,但这意味着您不必指定所有工具和库(CC,CXX,RANLIB, - with-ibfoo =等),因为它们是从标准惯例.从理论上讲,您可以在多个项目中重复使用适当制作的CMake工具链文件来交叉编译它们.在实践中,CMake的普及程度不足以使普通黑客更方便,但如果您创建多个专有项目可能会有用.
几年前我使用Ant + CppTasks来构建通过JNI集成到新Java代码中的非常大的代码库,并且非常满意C++代码非常可靠的增量构建的结果,良好的灵活性(在构建文件中,或通过调整代码).但是,CppTasks是一个没有社区的项目,维护者(Curt Arnold)很长一段时间没有做任何事情.它仍然非常好用,但要注意很少有人知道或使用CppTasks(例如当我需要一个特定的C文件编译器时,编译器"竞标"文件的方式会让我感到困惑,并且不同的C++编译器正在挑选它们代替).
CppTasks跟踪编译选项的方式,以及动态扫描源依赖关系的方式,总是足够快(存在一些依赖关系的缓存),这意味着我使用过的唯一具有准确增量构建的系统,这一点非常重要构建非常大的代码库.
因此,我已经在Ant用户/开发人员列表上说了几次,如果你有很多Java的东西并且已经在Ant上投资了,并且不怕潜入CppTasks 的文档和代码,现在需要构建JNI"粘合"代码,和/或胶水代码公开的"遗留"本机库,这是一个有价值的竞争者,奖励可能很棒.
我轻松地将
我希望这有帮助.--DD
京公网安备 11010802040832号 | 京ICP备19059560号-6 