构建C项目的正确方法是什么?制作/ IDE /蚂蚁……?

前端之家收集整理的这篇文章主要介绍了构建C项目的正确方法是什么?制作/ IDE /蚂蚁……?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
有多种方法可以管理项目的构建.我知道这些可能性:

>制作
> IDE
>蚂蚁
> Maven

我们可以说其中一些(或者其他一些我不知道的吗?)总体上优于其他项目,并且在新项目中应该是首选吗?

此时我在我的项目中使用Eclipse IDE管理的构建,我考虑迁移到makefile.不知何故,我觉得它会更易于管理,但另一方面,实际上IDE的目标是使事情更易于管理.所以,我只是想做有害的工作,试图回归老式的东西?我从Java项目中获得了很好的Maven经验,但用C强制它是个好主意(虽然我知道它可能……)?

解决方法

大多数C构建系统仍然存在,出于某种原因这样做.也就是说,它们在某种程度上比替代品更好. (除了你编写XML的构建系统,对不起ANT)

但总的来说,我们看到一些使用模式出现了.

您通常只能看到用于MSVC和XCode的IDE项目.这是因为与IDE的更好的集成,是的.但更重要的是,平台. IDE项目特别支持VC,除非最终生成项目,否则通常支持非常差.我从来没有见过用eclipse构建的c项目,但这可能与没有看到在Eclipse中编写代码的c程序员有关.

在unix平台上,您通常会看到正在使用的一些Makefile变体.这似乎与想要一个最不常见的恶魔建造者来构建项目有关,因为大多数代码都是以源代码形式分发的.

当平台独立性成为首要任务时,通常会使用像CMake(项目生成器)这样的项目,由于生成 – >构建步骤,您会获得一些开销,但是可以从单个构建库在多个平台上构建项目.

我真的只看到ANT用于执行连续构建,即便如此,通常它会调用单独的构建步骤,我不知道为什么会这样.

然后我也看到了针对* nix / Mac或其他不太常见的平台的专有项目中的Jam(制作替换)等大量用法.特别是在游戏开发中,我认为这通常来自团队,这些团队就像Make in the theory(处理你的构建源的概念,就像你对待你的代码,没有WYSIWYG之类的东西),但是要明白Make是破碎的.然而,不必进行源代码分发.

这只是我观察到的一系列模式,并试图使其合理化,这很少基于客观真理.

原文链接:https://www.f2er.com/c/117306.html

猜你在找的C&C++相关文章