我刚刚发布此内容作为对“最佳”错误跟踪软件问题的回复的一部分......
嗯，一个工具本身就是一个工具。虽然所有人都谈到工具链，但大多数只是指工具的松散集合。为什么不寻找一个“与其他孩子一起玩得很好”的问题跟踪器？也就是说，与IDE，构建工具，版本控制系统接口良好......
事实上，我想我现在就去问一个关于最好的链接工具链的问题......
那么，有什么评论吗？我更希望回复在Linux上开发C / C ++并使用FOSS（但如果您认为它会帮助其他人，请不要让它阻止您发布基于Windows的答案）。我们不需要一个完整的链条，但也许一些链接工具组仍然比链中完全独立的“链接”更好。
我用
我似乎缺少一个项目管理工具，它与工具链中的其他“链接”接口。我们如何完成它，端到端，还有一个“最佳”链（或者至少是一个链接最多的链）？
编辑：我们不要忘记需求跟踪和项目规划＆amp;跟踪 - 结束编辑
并且每个人都描绘了各种工具之间的关系（即哪个接口与哪个接口，哪个方向可以以另一个的导入格式导出等）？
答案 0 :(得分：9)
天儿真好，
根据我的经验，我发现尝试提出一个“明确的”工具链可能会导致问题。
最糟糕的一点是它倾向于迫使人们进入项目的“一切看起来像钉子”的方法。也就是说，您已经完成了选择您认为合适的工具的工作，现在您已经拥有了工具套件。
根据我的经验，一旦选择并设置了工具集，就很难让人们为其他项目更改他们的“规范集”工具。
我已经做了20多年，现在已经在从船上潜艇声纳模拟器到空中交通管制显示系统到直升机控制系统的各种项目中这样做了。即使在同一家公司内，不同的项目也需要不同的工具来解决将要遇到的各种问题。
您可能会认为，一旦为特定目的选择了工具，您就可以将该工具重新用于所有项目，例如：您选择的BugZilla进行错误跟踪。但是，如果没有合适的SMTP服务器可用，因为你有一个分布式团队，而你的邮件服务器是内部的，锁定的，安全的，例如。
我建议最好建立一套可用的工具，您可以从中选择项目的工具套件。例如，添加Trac或FogBuzz作为可能的错误跟踪机制。
很多事情会影响您选择的工具。在我的头顶，我有：
有一套可能性可以最大限度地减少“试图将方形钉子挤入圆孔”的效果。
无论如何，您可能会发现您可以在一段时间后减少您的可能性，因为您可以展示成功的方法，因此在公司内获得足够的牵引力，以支持您以前的方式做事做完了。
HTH
答案 1 :(得分：1)
我认为Unix philosophy会阻碍这些紧密集成的工具链。 Eclipse，你提到的第一件事，来自Java世界，这绝非偶然。 Unix（以及扩展名，Linux）倾向于相信所谓的“插件”更少，而且在共享存储在平面文本文件中的数据的工具集中更多。
通过“项目管理”，我不确定您是否意味着Make或者其他东西可以跟踪您团队的进度。如果你的意思是Make，那么Unix世界非常需要一个可重用的Make，它支持“智能重新编译”，并且可以与多个编译器一起使用。最接近的是Glenn Fowler's nmake，但这并不是非常接近。
关于更一般地集成工具集，
我见过的最好的工具集是在AT＆amp; T建立的Advanced Software Technology工具。有一本最优秀的书Practical Reusable Unix Software，可以免费下载，它描述了大约1995年的游戏状态。从那以后，这个工具集变得更好更丰富了，但是要了解到底是怎么回事，你真的需要这本书。这些人从贝尔实验室的Unix小组开始，他们创造的不仅仅是工具链，而是一种生活方式。乔鲍勃说要检查一下。
许多Unix工具链中另一个无处不在的元素是（这可能会让你发笑或呕吐）Emacs。虽然Emacs Lisp不是任何人最喜欢的编写插件或扩展的方式，但随着时间的推移，Emacs已经成为一个非常丰富，强大的编程环境 - 它可以与各种其他工具进行对话。我是简单的，而不是复杂的，所以我试着保持浅水，但如果你真的想要研究Unix的工具链，那就明白了。
我期待看到你问题的更多答案。
答案 2 :(得分：0)
它不是FOSS，但Rational提供了一个完整的工具链（编译器除外），
您可以获得IDE，类图，用例，需求跟踪，测试工具，问题记录工具，这些工具可以很好地集成到几千（或数百）美元。
无（来自建模工具的aprt）是最好的，但是，它们都非常好并且彼此很好地集成。
声明： - 我选择的“工具集”是vim，make，ddd，gmail和用于建模的moleskin笔记本。