如何有效处理大型Linux / makefile项目？

我从事C ++ Windows应用程序开发已有10年了。最近，我开始研究一些Linux项目，我无法忍受如此无用的工作...

我学习速度很快，并且一段时间以来我一直在使用Linux作为主要平台。而且我对shell，OS原理和GUI感到非常满意。但是当涉及到开发时，感觉就像我回到了学校。

一旦我打开一个更大的项目，我就被卡住了。它们中的大多数都是基于makefile的，因此基本上，当我尝试使用QT或CodeBlocks导航它们时，充其量，我可以基于每个文件使用intellisense。而且大多数时间变量都从作用域泄漏。

然后是一个似乎没有定义的东西，尝试从sourceforge加入一些更大的项目，并且您被困了好几天，因为导航到定义是如此困难…… grep -r "this_def" . --include "*.cpp" --include "*.h"似乎太慢而且笨拙。

然后，调试gdb确实可以工作，但是无论我做什么，似乎WinDbg或VisualStudio调试器都落后了光年。

这些事情使我感到绝望，我想编写代码，但是过程太慢了……我开始认为Linux开发人员会心地学习函数定义并通过眼睛来分析代码，但是我不敢相信所以。

有人经历过这个吗？有什么我想念的东西可以使我更有生产力吗？

有趣的是，我经常在相反的方向遇到相同的问题。我主要是UNIX编码器，但是我必须定期将东西移植到Windows。我无法告诉您要拔出头发的次数，因为找不到适合35个首选项设置页面之一中的编译器选项的适当复选框。我宁愿只是打开proj文件并自己添加XML。

朝着任一方向前进，秘诀就是要有耐心，并为要尝试使用的平台学习工具集。一遍又一遍。无法避免这种情况。

在您的特定情况下，您应该注意一些其他工具。第一个是DDD，它是gdb的GUI前端。它不像Visual Studio那样漂亮，但是可以握住您的手。但是，我真的建议您忍耐一下，开始学习gdb的来龙去脉。实际上，如果您是普通用户，则记住要键入的命令与记住要更改设置必须显示的对话框之间没有太大区别。

您还需要了解CScope和CTags之类的工具。尽您所能抗拒，我建议您学习VIM或EMACS。它们与我刚才提到的标记工具很好地集成在一起。在罗马做到入乡随俗。您可以找到VIM和EMACS的扩展，这些扩展将为您完成代码。我对提供代码完成功能的工具的经验是，是的，它确实节省了一些键入操作，但总的来说键入操作很容易。思考是很难的。您的意见可能会有所不同，特别是如果您患有腕管综合症。

至于make。Make确实很可怕，但是您可能只需要吸吮它并学习它。

我从事C ++ Windows应用程序开发已有10年了。最近，我开始研究一些Linux项目，我无法忍受如此无用的工作...

有什么我想念的东西可以使我更有生产力吗？

在Windows上开发，在Linux上部署。

这包括在您自己的（Windows）机器和构建服务器（Linux）上运行单元测试。

作为副作用，您将学习如何编写可移植的代码。

另一个积极的效果是，使用不同的编译器将生成更多的警告，从而捕获更多的错误。

更新：对于所有对此投票否决的Linux迷来说：我并不是说每个人都应该在Windows上进行开发！但是，使用非常熟悉的平台比花很多时间学习新平台更有效。

您的问题在Linux世界中已经解决了很多次，但是，与Windows / Microsoft工具不同，它不会像其他工具那样被放到一块银板上。您可能需要做一些工作才能得到它。

对于这个确切的问题，我使用了商业编辑器（Visual Slick Edit，那些认为时间不如我认为昂贵的编辑器）。带有CDT插件的Eclipse是一种开放源码的方式，拥有可观的大量支持者。（对我不利，因为我经常需要ADA支持）

我不尝试将Makefile反向工程为某种项目。我使用IDE的内置系统，并根据需要手动添加/删除文件。我确定我可以编写脚本，但是时间可能不值得。为此，我发现日食比Slickedit少了一些（自从我上次看过以来，这很容易（并且可能已经改变了））

Linux有各种各样的工具，熟悉vi的人在编辑的各个方面都比我好，它具有参考查找等功能，只是学习曲线很陡。我相信Emacs也可以做到，尽管从未使用过它。

就其价值而言，在Linux上，您具有比普通的旧GNU make（通常与可怕的autoconf一起使用）更好的构建系统，例如omake和许多其他的（cmake，scons...）。

关于使用grep搜索代码有多繁琐的一个建议：在.bashrc文件中设置bash别名。因此，这只是一个命令：

alias searchCode='find -iname \*.cpp | xargs grep $1'
alias searchCodeHeaders='find -iname \*.h | xargs grep $1'

也许有更好的方法来编写命令，但是想法是一样的。要搜索代码吗？写一个叫做searchCode的别名。请记住，尽管它们繁琐而复杂，但是unix工具也可以用来使您的生活更轻松。

我的2c是在两个平台上都开发过C ++并同时喜欢两者的人。

1）Makefile很痛苦-如果可以的话，我能给您的最好建议是尝试切换到另一个构建系统。

2）对于代码编辑和浏览，有一些非常有用的工具。当然，它们没有集成在一起，但是完成工作并不重要。vim + ctags + grep会带您到达那里。当然，也有IDE，但是坦率地说，我不喜欢尝试的任何东西：Eclipse + CDT，KDevelop，Code :: Block。但是，您可能得出不同的结论。

3）要进行调试，只需坚持使用命令行gdb。当然，在功能方面，它远远落后于Windbg，但是对于大多数目的来说，这还不错。我上次尝试使用图形化前端（ddd，KDbg）时遇到了很多麻烦，但情况可能再次发生了变化:)

底线是-是的，您需要付出一些学习努力，但是之后您将像在Windows上一样高效。

对于您已经收到的所有其他好的建议，我想分别添加几个链接到 ack和pss。

它们针对需要特别关注源代码，试图在grep之上进行改进的程序员。

好答案。加上他们，

当我采取这一行动时，我犯的错误是试图跳入代码而没有对GNU构建系统进行尽职调查，当我想对代码进行更改时，这又让我很反感。花几天的时间来了解AutoMake / AutoConf / Make工具套件的工作方式，之后您会很快。

关于工具-Eclipse + CDT / GDB + DDD确实走了很长一段路。

以下是一些建议，以使其更容易工作：

1. 从头开始。这意味着您将首先使用bash脚本作为makefile替换，然后在需要依赖项时使用简单的makefile。一开始要保持简单。您的makefile不需要处理15种不同的unix平台-只需使其具有依赖项即可进行编译。（您的初始makefile看起来像：all：g ++ -o main main.cpp）（更复杂的示例可以从http://sivut.koti.soon.fi/~terop/Makefile中找到-从头开始时，只需将文件复制到项目，更改文件名，mkdir objs目录，更改所需的库）
2. 忘记IDE。这只会让你变慢。学习阅读代码并记住项目的文件层次结构。诸如“ cd dir”和“ emacs foo.cpp”之类的常规命令行工具必须非常自动，以至于您不必三思而后行。
3. 忘记语法高亮和智能感知。它永远不会像在Visual Studio上一样工作，而且它的提示只会使您感到困惑，因为它与您以前使用的有所不同。学会不依赖他们。
4. Gdb是一个很好的调试器。您将获得一个调用堆栈。甚至不要尝试单步执行代码，它不会很好地工作。也使用valgrind。断点也很好，但是不要过分地依赖它们。很少与gdb一起使用。
5. 如果您的编译不是shell中简单的“ make”编译，则需要重新考虑您的edit-compile-debug-edit -cycle。
6. 这是Visual Studio无法做到的一个技巧：同时在屏幕上同时显示头文件和.cpp文件-这样就可以在不使用标签之间切换的情况下看到它们。Emacs可以做到。记事本也可以。Visual Studio或IDE不能。
7. 了解emacs键绑定。这将使您更快。一个很好的提示是所有键都位于键盘的附近。命令序列更长，但键入它们仍然更快。
8. 有一个简单的技巧可以替换定义：将代码写入同一文件，然后在emacs中使用esc- <和Cs :: myfunction查找所需的功能。如果您习惯了许多短文件，则过程会有所不同-代码看起来会有所不同。（在记事本中学习ctrl -f，您将得到想法）。但是您绝对不需要在shell中执行此操作。
9. 文本编辑器的启动时间非常重要。如果打开时间超过1秒，那就不好了。由于此要求，每个IDE都损坏了。记事本和emacs都可以。
10. emacs中的goto-line是编程的重要功能。将其绑定到某个键。我用Cx g