我正在开发一个使用ant + cpptasks构建的大型C ++系统。它运行良好，但build.xml文件失控，因为添加新库或可执行目标的标准操作过程是复制并粘贴另一个lib / exe的规则（已经非常大）。如果这是“正确的代码”，它会为重构而尖叫，但作为一个蚂蚁新手（更习惯制作或VisualStudio解决方案）我不确定选项是什么。
什么是ant用户阻止ant build文件爆炸的最佳做法？
一个明显的选择是通过XSLT生成build.xml，为常见的重复模式定义自己的标记。有人这样做，还是有更好的方法？
答案 0 :(得分：13)
答案 1 :(得分：5)
如果规则是重复的，那么您可以使用macrodef将它们分解为一个ant宏并重用该宏。
如果文件的大小是无法管理的，那么您可以将其分解为较小的文件，并在这些文件中包含主build.xml调用目标。
如果它们都不是，那么您可能需要考虑使用构建系统。虽然我自己没有使用过Maven，但我听说它可以解决许多大型且难以管理的构建文件问题。
答案 2 :(得分：3)
通常，如果您的构建文件很大且很复杂，那么这清楚地表明您的代码布局方式，就文件夹和包而言，它复杂且过于复杂。我发现一个复杂的蚂蚁脚本清楚地表明了一个布局不佳的代码库。
要解决此问题，请考虑如何布置代码。你有几个项目？这些项目是否知道如何使用主构建脚本构建自己，该脚本知道如何将各个项目/应用程序/组件捆绑到一个更大的整体中。
当你重构代码时，你正在寻找方法或破坏它们以便它们更容易理解 - 更小的方法，更小的类，方法和类做一件事。您还需要将相同的原则应用于代码库。
创建功能更强大的小组件，并且与其余代码非常松散地分离。使用构建脚本将该组件构建到库中。使用其余代码执行此操作。现在创建一个主构建脚本，该脚本知道如何捆绑所有库并将它们构建到您的应用程序中。如果您有多个应用程序，那么为每个应用程序创建构建脚本，并创建一个知道如何将应用程序捆绑到可分发的主程序。
通过查看构建脚本，您应该能够看到并理解代码库的布局和结构。如果它们/它不干净且易于理解，那么您的源代码也不是。
答案 3 :(得分：3)
使用Antlib文件。
是一种非常干净的方式如果你想看一个例子，你可以看看我正在为我的沙箱项目写的一些build script。
答案 4 :(得分：1)
我会尝试Ant-Ivy- the agile dependency manager。我们最近开始将它用于一些更复杂的系统，它就像一个魅力。这里的优点是你没有得到maven的开销和转换成本（它使用ant目标，因此将与你当前的设置一起使用）。两者之间Here is a comparison。