リリースビルドモードとデバッグビルドモードの違いは理解できたと思います。主な違いは、デバッグモードでは、生成される実行可能ファイルが最適化されておらず(デバッグが困難になる可能性があるため)、デバッグシンボルが含まれていることです。
WinMergeの外部依存関係の1つであるPCREをビルドしているときに、これまで見たことのないビルドモードであるRelWithDebInfoに気づきました。
DebugとRelWithDebInfoの違いはここに記載されています: http://www.cmake.org/pipermail/cmake/2001-October/002479.html 。抜粋:「RelwithDebInfoはリリースモードと非常によく似ています。完全に最適化されたコードを生成しますが、プログラムデータベースを構築し、デバッグ行情報を挿入して、いつでもコードのどこにいるかをデバッガーが推測できるようにします。」
これは本当に良い考えのように聞こえますが、設定方法が必ずしも明白ではありません。このリンクでは、VC++でこれを有効にする方法について説明しています。 http://www.cygnus-software.com/papers/release_debugging.html
私は何かが足りないのですか、それともすべてのリリースコードをRelWithDebInfoとしてコンパイルするのは意味がありませんか?
私は何かが足りないのですか、それともすべてのリリースコードをRelWithDebInfoとしてコンパイルするのは意味がありませんか?
それは、デバッグ情報で顧客をどれだけ信頼するかによって異なります。
追加情報:
gccは、デバッグ情報をオブジェクトコードにエンコードします。
Gccに相当するpdbは次のとおりです。
ビルドターゲットの外部でgccデバッグシンボルを生成する方法は?
Cmakeはこのアプローチをすぐにサポートしているようには見えないことに注意してください。
私の知る限り、対応するデバッグシンボルを社内に保存せずにコードを顧客に出荷することは、本番環境の問題のデバッグに関しては脱毛のレシピです。
デバッグシンボルを使用したリリースビルドのデバッグは、デバッグビルドのデバッグとほとんど変わらないため、常にこれを行うことをお勧めします。
とはいえ、欠点があるかどうかはわかりません。もしそうなら、聞くのは面白いでしょう。
最適化されたリリースビルドをデバッグしようとすると、他に方法がない場合にのみこれを実行したい理由がわかります。
基本的に、これが必要になる場合は2つあります。
あなたのことはわかりませんが、過去10年間にリリースコードを2回または3回デバッグする必要があり、顧客のクラッシュが問題にならない企業で何とか働いていました。
ええ、リリースビルドのデバッグ情報も用意しておくことをお勧めしますが、VSはこのように設定しません。これが必要な、10年ごとの2つのケースでは、毎回手動で設定する価値はありません。時間。 CMakeは無料で提供しているので、やってください。
プロダクションコードは、デバッグ情報がもたらすサイズの肥大化を必要としません。
リリースビルド用にデバッグ情報が生成された場合でも、デバッグビルドよりもデバッグ目的での有用性ははるかに低くなります。その理由は、多くの変数と中間式が最適化されていないため、デバッガーで使用できないためです。