通常、メジャー バージョン番号とマイナー バージョン番号 (1.2 のように、1 がメジャーで 2 がマイナー) は、ほとんどの場合コードに直接、通常は #define として記述されます。 (条件付きコンパイル、つまり #if でそれらが必要になる可能性があるため ブロック）
通常、依存関係を最小限に抑えるために、これらの定義のみを含む別のヘッダー (ヘッダー ガードを除く) を用意します。
ビルド システム (cmake など) を使用してバージョン管理 (git、svn、cvs など) からバージョン番号を取得し、そのバージョン番号を「バージョン」ヘッダーに入れる人もいます。または、cmake チュートリアルに示されているように、バージョン番号をビルド システム構成ファイルに入れ、それをヘッダーに入れます。個人的には、このアプローチはあまり好きではありません。ヘッダー ファイルが頻繁に変更され、無意味な再コンパイルが頻繁に発生する傾向があるためです。
私は、ヘッダー ファイルにバージョン番号を書き込んでから、それらのバージョン番号 (メジャー、マイナー、..) をヘッダーからビルド システムに引き出すことを好みます。これは、cmake で非常に簡単に実行できるもう 1 つのことです。
ビルド番号やリビジョン番号など、非常に日ごとのバージョン番号をソフトウェアに埋め込みたい場合は、#define として配置しないでください。 ヘッダーファイルではなく、 extern const として 1 つの cpp ファイルで定義する変数。たとえば、cmake を使用してバージョン管理システムからリビジョン番号を取得し、それをこの extern const int revision; を定義する cpp ファイルに追加できます。 変数 (cmake の configure_file を使用) function) を作成し、プログラムをその cpp / object ファイルにリンクします。このように、リビジョン番号は再ビルドのたびにプログラムに自動的に組み込まれ、更新のたびに (コミットごとに) 完全な再コンパイルがトリガーされることはありません。
要点は、メジャー バージョン番号とマイナー バージョン番号は、何らかの自動メンテナンスを必要とするほど頻繁に変更されるわけではありませんが、手動で 1 か所にのみ書き込む必要があり、関連する可能性のある他のすべての場所に自動的に伝播する必要があるということです (この場所はヘッダーファイル自体です）。完全に自動化する必要があるのはリビジョン番号またはビルド番号のみです (バージョン管理によって生成され、他の場所に自動的に伝播されます)。
バージョン番号を専用のヘッダー ファイルに保持するのが通例だと思います。一部のツールは、これを自動的に生成できます。
たとえば、CMake チュートリアルの「バージョン番号と構成済みヘッダー ファイルの追加」セクションを参照してください。