Dav*_* L. 6 c++ build-automation build
有多种方法可以管理项目的构建.我知道这些可能性:
我们可以说其中一些(或者其他一些我不知道的吗？)总体上优于其他项目,并且在新项目中应该是首选吗？
此时我在我的项目中使用Eclipse IDE管理的构建,我考虑迁移到makefile.不知何故,我觉得它会更易于管理,但另一方面,实际上IDE的目标是使事情更易于管理.所以,我只是想做有害的工作,试图回归老式的东西？我从Java项目中获得了很好的Maven经验,但用C++强制它是个好主意(虽然我知道它可能......)？
Are*_*ius 11
大多数C++构建系统仍然存在,出于某种原因这样做.也就是说,它们在某种程度上比替代品更好.(除了你编写XML的构建系统,对不起ANT)
但总的来说,我们看到一些使用模式出现了.
您通常只能看到用于MSVC和XCode的IDE项目.这是因为与IDE的更好的集成,是的.但更重要的是,平台.VC++特别受IDE项目的支持,除了最终生成项目的东西外,其他方面通常都支持得很差.我从来没有见过用eclipse构建的c ++项目,但这可能与没有看到在Eclipse中编写代码的c ++程序员有关.
在unix平台上,您通常会看到正在使用的一些Makefile变体.这似乎与想要一个最不常见的恶魔建造者来构建项目有关,因为大多数代码都是以源代码形式分发的.
当平台独立性成为首要任务时,通常会使用CMake(项目生成器)等项目,由于生成 - >构建步骤,您会获得一些开销,但是可以从单个构建库在多个平台上构建项目.
我真的只看到ANT用于执行连续构建,即便如此,通常它会调用单独的构建步骤,我不知道为什么会这样.
然后我也看到了针对*nix/Mac或其他不太常见的平台的专有项目中的Jam(制作替换)等大量用法.特别是在游戏开发中,我认为这通常来自团队,这些团队就像Make in the theory(处理你的构建源的概念,就像你对待你的代码,没有WYSIWYG之类的东西),但是要明白Make是破碎的.然而,不必进行源代码分发.
这只是我观察到的一系列模式,并试图使其合理化,这很少基于客观真理.