有多种方法可以管理项目的构建。我知道这些可能性：
我们可以说其中一些（或者其他一些我不知道的吗？）总体上优于其他人，并且在新项目中应该是首选吗？
此时我在我的项目中使用Eclipse IDE管理的构建，我考虑迁移到makefile。不知何故，我觉得它会更易于管理，但另一方面，实际上IDE的目标是使事情更易于管理。所以，我只是想做有害的工作，试图回归老式的东西？我从Java项目中获得了很好的Maven经验，但用C ++强制它是个好主意（虽然我知道它可能......）？
答案 0 :(得分：11)
大多数C ++构建系统仍然存在，出于某种原因这样做。也就是说，它们在某种程度上比替代品更好。 （除了你编写XML的构建系统，抱歉ANT）
但总的来说，我们会看到一些使用模式出现。
您通常只会看到用于MSVC和XCode的IDE项目。这是因为与IDE的更好的集成，是的。但更重要的是，平台。 VC ++特别受IDE项目的支持，除了最终生成项目的东西外，其他方面通常都支持得很差。我从来没有见过用eclipse构建的c ++项目，但这可能与没有看到在Eclipse中编写代码的c ++程序员有关。
在unix平台上，您通常会看到一些Makefile的变体被使用。这似乎与想要一个最不常见的恶魔建立项目有关，因为大多数代码都是以源代码形式分发的。
像CMake（项目生成器）这样的项目经常在平台独立性成为首要任务时使用，由于生成 - >构建步骤，您会获得一些开销，但是能够在单个平台上构建项目buildbase。
我真的只看到ANT用于执行连续构建，即便如此，通常它会调用单独的构建步骤，我不知道为什么会这样。
然后我也看到了针对* nix / Mac或其他不太常见的平台的专有项目中的Jam（制作替代品）等大量用法。特别是在游戏开发中，我认为这通常来自团队，这些团队就像Make in the theory（处理你的构建源的概念，就像你对待你的代码，没有WYSIWYG之类的东西），但要明白Make是破碎的。然而，无需进行源代码分发即可享受奢侈品。
这只是我观察到的一系列模式，并试图使其合理化，但这很少基于客观真理。
答案 1 :(得分：6)
在寻求平台独立性时，我使用Cmake取得了不错的成绩。它的配置基于文本文件，它生成“真实”的构建脚本，如Makefile或适用于IDE的项目。如果您在介绍某种预构建步骤时没有问题，我会选择它。
在我可以保持平台依赖的情况下，我只是随心所欲。通常是Windows上的Visual Studio项目/解决方案和Linux上的Makefile。
答案 2 :(得分：1)
我假设您正在使用Eclipse CDT。构建过程实际上已经是基于Makefile的。但是，我认为CDT在编译时生成Makefile。也许其他人可以为我验证。无论如何，在CDT中你可以创建一个“Makefile”项目。这种类型的项目允许您使用预先存在的源及其Makefile，而不是从头开始。
要考虑的另一件事是您是否需要支持无头构建（例如，作为CI或其他自动构建过程的一部分）？如果是这样，那么你肯定会想要选择支持它的构建技术（比如Make）。
有关CDT如何使用Makefile的信息：Eclipse documentation