大規模なLinux / makefileプロジェクトに効果的に取り組む方法は？

私は10年ほど前からC ++でWindowsアプリケーションを開発しています。そして最近、私はいくつかのLinuxプロジェクトを掘り始めましたが、私がどれほど非生産的かは我慢できません...

私は早い学習者で、しばらくの間、Linuxを主要なプラットフォームとして使用しています。そして、シェル、OSの原則、GUIには非常に満足しています。しかし、開発に関しては、学校に戻ったように感じます。

より大きなプロジェクトを開くとすぐに行き詰まります。それらのほとんどはmakefileベースであるため、基本的にQTまたはCodeBlocksでナビゲートしようとすると、せいぜいファイルごとにインテリセンスを使用できます。そして、ほとんどの時間変数はスコープから漏れます。

次に、定義に移動するものがありますが、それは存在しないようで、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は確かに恐ろしいですが、おそらくあなたはそれを吸い込んで習得しなければならないでしょう。

私は10年ほど前からC ++でWindowsアプリケーションを開発しています。そして最近、私はいくつかのLinuxプロジェクトを掘り始めました。

生産性を高めるために足りないものはありますか？

Windowsで開発し、Linuxで展開します。

これには、独自の（Windows）マシンとビルドサーバー（Linux）の両方での単体テストの実行が含まれます。

副作用として、移植可能なコードの書き方を学びます。

別のプラスの効果は、異なるコンパイラを使用するとより多くの警告が生成されるため、より多くのバグが検出されることです。

更新：この答えを否定するすべてのLinuxファンに：誰もがWindowsで開発すべきだとは言いません！しかし、あなたがよく知っているプラ​​ットフォームを使用することは、新しいプラットフォームの学習に多くの時間を費やすよりも生産的です。

Linuxの世界では、あなたの問題は何度も解決されていますが、Windows / Microsoftのツールとは異なり、余分なものが付いた銀の皿には渡されません。あなたはそれを得るためにいくつかの作業を行う必要があるかもしれません。

私はこの正確な問題のために商用エディター（Visual Slick Edit、私と同じくらい時間を大事にしない人によって高価であると考えられている）を使用します。CDTプラグインを使用したEclipseは、正当な理由のある正当な理由を持つオープンソースの方法です。（ADAサポートが必要になることが多いので、私には良くありません）

私がやらないことは、メイクファイルを何らかのプロジェクトにリバースエンジニアリングしようとすることです。システムのIDEのビルドを使用し、必要に応じてファイルを手動で追加/削除します。スクリプトを作成できると確信していますが、時間はおそらく価値がありません。このため、私は日食がSlickeditより少し使いにくいことに気付きました（最後に見てから簡単に（おそらくおそらく）変更されました）

Linuxには膨大な数のツールがあり、編集のあらゆる面でviの性能が優れていることを知っている人たちは、参照ルックアップなどを備えており、学習曲線は急勾配です。Emacsはそれをすべて使用できると確信していますが、使用したことはありません。

それは価値があるものについては、Linux上で、あなたはより良い昔ながらよりシステム構築しているGNUのメイク（しばしば恐ろしいとなったautoconfを例にするために、）オマケ（および多くの他cmake、scons...）。

コードを検索するためにgrepを使用するのがいかに面倒かという1つの提案：.bashrcファイルにbashエイリアスを設定します。そのため、そのたった1つのコマンド：

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は15種類のUNIXプラットフォームを処理する必要はありません。依存関係を付けてコンパイルするだけです。（最初のmakefileは次のようになります：all：g ++ -o main main.cpp）（より複雑な例は、 http -最初から始める場合、ファイルをプロジェクトにコピーし、ファイル名、mkdir objsディレクトリを変更し、必要なライブラリを変更します）
2. IDEを忘れてください。遅くなるだけです。コードを読み、プロジェクトのファイル階層を覚えることを学びます。「cd dir」や「emacs foo.cpp」などの通常のコマンドラインツールは、2回入力することを考えないほど自動である必要があります。
3. 構文の強調表示とインテリセンスを忘れてください。Visual Studioでの動作と同じように動作することは決してありません。また、これまでの動作とは異なるため、そのヒントはユーザーを混乱させるだけです。それらに依存しないことを学ぶ。
4. Gdbは優れたデバッガーです。呼び出しスタックを取得します。コードを回避しようとしないでください。うまく機能しません。valgrindも使用します。ブレークポイントも優れていますが、それらにあまり頼らないでください。gdbではめったに使用されません。
5. コンパイルがシェルの単純な「make」以外の場合は、edit-compile-debug-edit -cycleを再考する必要があります。
6. Visual Studioではできないトリックを以下に示します。ヘッダーファイルと.cppファイルの両方を同時に画面に表示します。両方をタブで切り替えることなく表示できます。Emacsでできます。メモ帳もできます。Visual StudioまたはIDEではできません。
7. emacsキーバインドを学びます。速くなります。良いヒントは、すべてのキーがキーボードの非常に近くにあるということです。コマンドシーケンスは長くなりますが、入力する方が高速です。
8. go-to-definitionを置き換える簡単なトリックがあります。コードを同じファイルに書き込み、emacsでesc- <およびCs :: myfunctionを使用して、必要な関数を見つけます。多くの短いファイルに慣れている場合、プロセスは異なります。コードは異なって見えます。（メモ帳でctrl-fを学ぶと、アイデアが得られます）。ただし、シェルで実行する必要はありません。
9. テキストエディタの起動時間は非常に重要です。開くのに1秒以上かかる場合、それは良くありません。この要件のため、すべてのIDEが壊れています。メモ帳とemacsは大丈夫です。
10. emacsのgoto-lineはプログラミングの重要な機能です。いくつかのキーにバインドします。Cx gを使用します