大規模なLinux / makefileプロジェクトに効果的に取り組む方法は？
私はWindowsアプリケーションをC++で10年ほど開発してきました。そして最近、私はいくつかのLinuxプロジェクトを掘り下げ始めました、そして私がどれほど非生産的であるか我慢できません...
私は早い学習者で、しばらくの間Linuxをプライマリプラットフォームとして使用しています。また、シェル、OSの原則、およびGUIに非常に満足しています。しかし、開発に関しては、私は学校に戻ったような気がします。
より大きなプロジェクトを開くとすぐに行き詰まります。それらのほとんどはメイクファイルベースであるため、基本的には、QTまたはCodeBlocksを使用してナビゲートしようとすると、最高でもファイルごとにIntelliSenseを使用できます。そして、ほとんどの場合、変数はスコープからリークします。
次に、存在しないように見える定義に行くものがあります。sourceforgeからいくつかの大きなプロジェクトに参加してみてください。定義に移動するのは非常に難しいため、何日も行き詰まっています... grep -r "this_def" . --include "*.cpp" --include "*.h"はとても遅くて不器用に見えます。
そして、デバッグ、gdbは機能しますが、私が何をしても、WinDbgまたはVisualStudioデバッガよりも数年遅れているようです。
そして、これらのことは私を必死にさせています、コードを書きたいのですが、それはとても遅くなります... Linux開発者は関数定義を暗記し、コードを目で分析していると思い始めていますが、それは信じられませんそう。
誰かがこれを経験しましたか？私の生産性を高めるために欠けているものはありますか？
興味深いことに、私は定期的に反対方向に同じ問題を抱えています。私は主にUNIXコーダーですが、Windowsに定期的に移植する必要があります。プロジェクトの35個の設定ページの1つに埋め込まれているコンパイラオプションの適切なチェックボックスが見つからないため、髪の毛を抜いたかった回数はわかりません。 projファイルを開いてXMLを自分で追加したいだけです。
どちらの方向に進んでも、忍耐を持ち、作業しようとしているプラットフォーム用のツールセットを習得することが秘密です。もう一度。これを回避する方法はありません。
あなたの特定のケースでは、あなたが知っておくべきいくつかの追加のツールがあります。 1つ目は、gdbのGUIフロントエンドである [〜＃〜] ddd [〜＃〜] です。 Visual Studioほど滑らかではありませんが、あなたの手を握ります。しかし、私は本当に弾丸を噛むことをお勧めし、gdbの詳細を学び始めます。実際、通常のユーザーであれば、入力するコマンドを記憶することと、設定を変更するために表示する必要があるダイアログボックスを記憶することとの間に大きな違いはありません。
CScope や CTags などのツールについても知る必要があります。あなたが抵抗するかもしれない限り、私は [〜＃〜] vim [〜＃〜] または [〜＃〜] emacs [〜＃〜] を学習することをお勧めします。これらは、先ほど述べたタグツールとうまく統合されます。ローマにいるときは、ローマ人と同じようにしてください。コード補完を行うVIMとEMACSの拡張機能を見つけることができます。コード補完を提供するツールでの私自身の経験は、はい、タイピングを節約しますが、一般的にタイピングは簡単です。特に難しいのは思考です。手根管症候群の場合は特に、意見が異なることがあります。
メイクも。 Makeは確かに恐ろしいですが、おそらくあなたはそれを吸い取ってそれを学ぶ必要があるでしょう。
私はC++でWindowsアプリケーションを10年ほど開発しています。そして最近、私はいくつかのLinuxプロジェクトを掘り下げ始めました、そして私がどれほど非生産的であるか我慢できません...
生産性を高めるために欠けているものはありますか？
Windowsで開発し、Linuxでデプロイします。
これには、独自の（Windows）マシンとビルドサーバー（Linux）の両方でユニットテストを実行することが含まれます。
副作用として、移植可能なコードを書く方法を学びます。
別のプラスの効果は、異なるコンパイラを使用すると、より多くの警告が生成され、より多くのバグをキャッチできることです。
[〜＃〜] update [〜＃〜]：この回答に反対票を投じているすべてのLinuxファンに：私は誰もがWindowsで開発するべきだとは言いません！しかしよく知っているプラットフォームを使用する方が生産性が高い新しいプラットフォームの学習に多くの時間を費やすよりも。
あなたの問題はLinuxの世界で何度も解決されていますが、Windows/Microsoftのツールとは異なり、エキストラのおかずが付いた銀製のプレートには渡されません。取得するには、いくつかの作業が必要になる場合があります。
この正確な問題については、商用エディター（Visual Slick Edit、時間をあまり重視しない人には高価だと考えられています）を使用しています。 CDTプラグインを備えたEclipseは、オープンソースの方法であり、正当な根拠があります。 （私はよくADAサポートを必要とするので私にとっては役に立ちません）
私がしていないことは、メイクファイルをある種のプロジェクトにリバースエンジニアリングすることです。 IDEのビルドインシステムを使用し、必要に応じて手動でファイルを追加/削除します。私はそれをスクリプト化できると確信していますが、時間はおそらくそれだけの価値はありません。このため、EclipseはSlickeditよりも少し使いづらいことがわかりました（それは最後に見た後で簡単に（そしておそらく変更されているかもしれません）変更されました）
Linuxにはさまざまなツールがあり、viが編集のあらゆる面で私より優れていることを知っている人、参照のルックアップなどがあり、学習曲線が急です。私はEmacsもそれをすべて実行できると確信していますが、使用したことはありません。
コードを検索するためにgrepを使用するのがどれほど面倒かに関する1つの提案：.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と同じように生産性が向上します。
素晴らしい答え。それらに加えて、
私がこの動きをしたとき、私が犯した間違いは、GNUビルドシステムに十分な注意を払わずにコードに飛び込もうとしたことでした。 。AutoMake/AutoConf/Makeツールスイートがどのように機能するかを理解するのに数日かかりますが、その後は非常に速くなります。
ツールに関して-Eclipse + CDT/GDB + DDDは確かに長い道のりです。