ビルドシステムの概要

GROMACS のビルドシステムは、ユーザーが選択したビルドツールに対応する実際のビルドシステムを生成するために、CMake (バージョン 3.28 以降) を使用します。CMake の一般的な導入と使用方法については、CMake のドキュメントを参照してください。このドキュメントは、GROMACS のビルドシステムの構成と実装、および開発者向けの機能 (高度なユーザーにも役立つ可能性のあるものを含む) に焦点を当てています。

ほとんどの開発者は、``make``または``ninja``を基盤とするビルドシステムを使用しているため、これらのツール向けに特定のコマンドラインでの使用を目的として設計されたビルドシステムの要素が存在する可能性があります。これらの要素は、他の環境ではうまく動作しない可能性があるものの、CMakeがサポートするすべての環境で基本的なビルドは可能です。

また、ビルドシステムとバージョン管理は、ソースコード外でのビルドを前提として設計されています。ソースコード内でのビルドも、ほとんどの場合（一部のカスタムターゲットを除く）は正常に動作しますが、例えば、ビルド出力全体を除外する：file:`.gitignore`ファイルや、`clean`ターゲットを使用してすべてのビルド出力を削除するなどの機能は、特に実装されていません。

ビルドの種類

ビルドの種類は、CMakeの概念であり、特定のプラットフォーム上でビルドツールが使用され、実行可能コードを生成する方法を全体的に制御します。これらの種類は、コマンドライン（例：cmake -DCMAKE_BUILD_TYPE=Debug）など、さまざまな方法でCMakeで設定できます。|Gromacs|は、以下の標準的なCMakeビルドの種類をサポートしています：

リリース

本番シミュレーションで使用することを目的とした、完全に最適化されたコード。これがデフォルトです。

デバッグ

コンパイルされたコードは、デバッグツールとの使用を目的としており、最適化レベルが低く、シンボルに関するデバッグ情報が含まれています。

RelWithDebInfo

リリース版と同様ですが、シンボル名のデバッグ情報が含まれており、最適化されたコードでのみ発生する問題のデバッグに役立ちます。

MinSizeRel

リリース版と同様ですが、生成される実行ファイルのサイズを最小限に抑えるように最適化されています。これは|Gromacs|のインストールでは通常問題になりませんが、使用する必要はありませんが、おそらく動作する可能性があります。

さらに、|Gromacs|は開発およびテスト用の以下のビルドタイプを提供します。これらの実装は、「cmake/gmxBuildTypeXXX.cmake」にあります。

参照

このビルドタイプは、|Gromacs|のバージョンを、正確性にのみ焦点を当ててコンパイルします。 すべての並列化および最適化は無効化されます。 このビルドタイプは、GCC 11を使用してコンパイルされ、他のすべての|Gromacs|ビルドとの比較に使用される、回帰テストの参照値を生成します。

RelWithAssert

リリース版と同様ですが、コンパイラのコマンドラインから -DNDEBUG を削除します。これにより、すべてのアサーションステートメントが有効になり（これにより、GROMACS および依存コードに、関連する副作用が発生する可能性があります）。

プロファイル

リリース版と同様ですが、プロファイリングツールとの使用を可能にするために -pg オプションを追加しています。これは、:ref:`gmx mdrun のパフォーマンスプロファイリングには効果がない可能性がありますが、他のツールには役立つ場合があります。

TSAN

ビルド GROMACS を、GCC および Clang で ThreadSanitizer を使用して、データ競合を検出するために利用します。これにより、ThreadMPI での原子演算の使用を無効にし、代わりにミューテックスベースの実装を使用します。

ASAN (AddressSanitizer)

ビルド GROMACS を、GCC および Clang での AddressSanitizer を使用して、さまざまな種類のメモリ使用ミスを検出するために使用します。 デフォルトでは、AddressSanitizer に LeakSanitizer (LSAN) が含まれていますが、多くの場合は GROMACS が、特定の関数（メモリリークが発生しやすい関数）またはまとめてリーク検出を無効にします。

MSAN

Gromacs のビルドにおいて、Clang の MemorySanitizer (<https://clang.llvm.org/docs/MemorySanitizer.html>) を使用して、初期化されていないメモリへのアクセスを検出します。この機能を使用するには、Gromacs の依存関係が、互換性のある方法でビルドされている必要があります（具体的には、静的ライブラリを -g -fsanitize=memory -fno-omit-frame-pointer オプションでビルドする必要があります）。通常、C++ 標準ライブラリも特別な方法でビルドする必要があります。このビルドタイプで使用する依存関係のヘッダーファイルとライブラリが置かれるべきパスは、CMake のキャッシュ変数 GMX_MSAN_PATH で設定されます。現時点では、内部の XDR と内部の fftpack のみサポートされています。

UBSAN (アンチサンドボックス違反検出)

Gromacs のビルド |GCC および Clang で UndefinedBehaviorSanitizer を使用して、実行中に未定義の動作を検出します。 実行時に行われるチェックにはわずかなコストがかかり、アドレス空間レイアウトやアプリケーションのバイナリインターフェースに影響を与えません。

すべてのサニタイザービルドで、読みやすいスタックトレースを得るには、ASAN_SYMBOLIZER_PATH``環境変数（またはあなたの``PATH）に``llvm-symbolizer``バイナリのパスが含まれていることを確認する必要があります。

一部のジェネレーターを使用すると、CMakeは1回のパスで複数の CMAKE_BUILD_TYPE を生成するため、CMakeLists.txt ファイル内で直接 CMAKE_BUILD_TYPE を使用するコードは壊れる可能性があります。GROMACS はこのような CMake コードを使用しているため、これらのジェネレーター（Visual Studio などを含む）では、すべてのビルドタイプを完全にサポートしていません。

CMake キャッシュ変数

このセクションでは、開発者や上級ユーザーが設定して、CMakeが生成する内容や、ビルドされる内容に影響を与えることができる（ただし、現時点では不完全な）キャッシュ変数のリストを提供します。

コンパイラオプション

標準のCMakeメカニズムとして、すべてのビルドタイプに影響を与えるフラグには``CMAKE_C_FLAGS``/``CMAKE_CXX_FLAGS``を使用し、特定のビルドタイプにのみ影響を与えるフラグには、CMAKE_C_FLAGS_buildtype/:samp:`CMAKE_CXX_FLAGS_{buildtype}`を使用します。CMakeには、いくつかのデフォルトのフラグが用意されています。

GROMACS は、以下の2つのカテゴリに分類された、独自のデフォルトフラグを決定します。

  • 上記のデフォルトの CMake フラグ変数に付加される一般的なフラグ。これらは通常、使用する最適化フラグを指定し、コンパイラの警告を制御するために使用されます（複数のビルドタイプの場合）。

  • 特定の機能に対して、ビルドシステムが正常なコンパイルのために必要と判断した特定のフラグ。例えば、コンパイラが使用/サポートできるSIMD命令セットを決定するフラグの例があります。

上記すべてのフラグは、指定されたコンパイラで正常に動作することを確認した後に追加されます。

自動コンパイラフラグの動作を制御するためのキャッシュ変数が1つあります。

GMX_SKIP_DEFAULT_CFLAGS

「ON」に設定されている場合、ビルドシステムは自動的にコンパイラフラグを追加しません（上記の定義どおりの汎用的なフラグも、特定のフラグも）。また、ほとんどのリンカフラグもスキップします。デフォルトで追加されるはずだったフラグは、`:command:``cmake`を実行するときに表示され、ユーザーはCMake変数を使用してそれらのフラグを手動で設定できます。「OFF」（デフォルト）の場合、上記の記述どおりにフラグが追加されます。

デフォルトの汎用フラグを決定するコードは、cmake/gmxCFlags.cmake にあります。具体的なフラグ（例：SIMDフラグ）を設定するコードは、主要な CMakeLists.txt にあります。 GMX_SKIP_DEFAULT_CFLAGS を検索してください。この変数で使用されている値は、実際に使用するフラグが決定される場所を追跡できます。

コンパイル/リンクに影響を与える変数

GMX_BROKEN_CALLOC

malloc/memset を使用して calloc のエミュレーションを有効にします。これは、calloc(3) が破損しているマシンでのみ必要です（例：Cray XT3 で -lgmalloc を使用）。デフォルトでは OFF に設定されており、必要な場合にのみ変更する必要があります。

GMX_BUILD_FOR_COVERAGE

特別な変数 ON は、カバレッジのジョブでビルドを行う際に、CI によって設定されます。これにより、ビルドシステムは、可能な限り有用なカバレッジ指標を生成するためのオプションを設定できます。現在、これはすべてのアサーションを無効にして、それらが不適切な条件付きカバレッジとして表示されないようにしています。デフォルトは OFF であり、手動でのビルドでは変更する必要はありません。

GMX_BUILD_OWN_FFTW

「ON」に設定した場合、|Gromacs|のビルドシステムは、FFTWを自動的にソースからダウンロードしてビルドします。Windows環境または「ninja」ビルドシステムではサポートされていません。複雑な状況（例えば、クロスコンパイル時やツールチェーンファイルを使用する場合）では、この機能を依存せず、FFTWを手動でビルドすることをお勧めします。

GMX_BUILD_SHARED_EXE

実行ファイルを共有ライブラリとしてビルドします。設定されていない場合、`-rpath`および動的リンカのフラグを無効にし、静的バイナリのビルドを試みます。ただし、これには適切なツールチェーンのセットアップと、必要なライブラリの提供が必要になる場合があります。デフォルトでは「ON」に設定されます。

GMX_COMPILER_WARNINGS

設定が ON の場合、CI が使用する検証用のコンパイラで、さまざまなコンパイラ警告が有効になります。ソース tarball からビルドする場合、デフォルトで OFF に設定され、CI でテストされていないバージョンでコンパイルするユーザーが、当社が使用する、警告を大量に発生させる可能性のある、より強力な警告フラグの影響を受けないようにします。Git リポジトリからビルドする場合、デフォルトで ON に設定されます。

GMX_CYCLE_SUBCOUNTERS

「ON」に設定すると、デフォルトのカウンターよりも詳細な mdrun のパフォーマンス測定と評価を提供するサブカウンターを有効にします。サブカウンターの詳細については、：ref:mdrun から最適なパフォーマンスを得る を参照してください。デフォルトでは「OFF」です。

GMX_ENABLE_CCACHE

「ON」に設定した場合、繰り返しビルドを高速化するために、ccache キャッシングコンパイララッパーを設定しようとします。 CMake が互換性のあるビルドタイプで実行されている場合、find_package() を使用して ccache 実行可能ファイルを探します。 実行可能ファイルが見つかり、互換性のあるコンパイラが構成されている場合、CMake 起動ラッパースクリプトが設定されます。 また、ccache 実行可能ファイルが CMake によって検出された場所は、ビルド中にアクセス可能である必要があります。 デフォルトでは「OFF」に設定されており、ビルドシステムの複雑さを最小限に抑えます。

GMX_INSTALL_DATASUBDIR

設定するサブディレクトリは、CMAKE_INSTALL_DATADIRの下にある、GROMACS-固有の読み取り専用、アーキテクチャに依存しないデータファイルがインストールされる場所です。 デフォルトは gromacs で、これによりファイルは share/gromacs の下に配置されます。 share の部分を変更するには、CMAKE_INSTALL_DATADIR を変更します。 これがビルドにどのように影響するかについては、ファイルが可搬化されたバイナリ を参照してください。

GMX_DOUBLE

GROMACS の多くの部分が「実数」精度で実装されており、実際には単精度または倍精度いずれかのタイプを使用しています。この設定によって、コードの一部が意図的に単精度または倍精度タイプを使用しており、この設定には影響されません。詳細については、混合または倍精度 を参照してください。

GMX_EXTERNAL_BLAS

デフォルト（設定されていない場合）、CMakeは最初に外部のBLASライブラリを使用しようとします。失敗した場合は、|Gromacs|に同梱されているものを使用します。 ``OFF``に設定すると、CMakeは同梱されているものをすぐに使用します。 ``ON``に設定すると、CMakeは外部のものを使用し、見つからない場合はエラーを発生させます。

GMX_EXTERNAL_LAPACK

参照してください GMX_EXTERNAL_BLAS.

GMX_EXTERNAL_TNG

外部のTNGライブラリを使用して軌跡ファイルの処理を行います。 デフォルト: OFF.

GMX_FFT_LIBRARY

利用するCPU FFTライブラリを選択します。 可能な値: fftw、mkl、fftpack。 デフォルトの選択は、コンパイラとビルドの種類によって異なります。

GMX_GIT_VERSION_INFO

各ビルドに対して、gitから動的にバージョン情報を生成するかどうか（例：HEADのコミットハッシュ）。デフォルトは ON で、ビルドがgitリポジトリから行われ、コマンド git が見つかった場合に適用されます。それ以外の場合は OFF になります。 OFF の場合、静的なバージョン情報は cmake/gmxVersionInfo.cmake から取得されます。

GMX_GPU

GPUオフロード用のバックエンドを選択します。 可能な値: CUDA、OpenCL、SYCL。 詳細については、インストールガイド を参照してください。

GMX_CLANG_CUDA

CUDA GPU コード（ホストとデバイスの両方）のコンパイルには、clang を使用してください。詳細については、インストールガイド を参照してください。

GMX_CUDA_CLANG_FLAGS

この変数を使用して、clang に追加の CUDA 固有のコンパイラフラグを渡します。

CMAKE_INSTALL_LIBDIR

ライブラリのインストールディレクトリを設定します（デフォルトは、標準のCMakeパッケージ「GNUInstallDirs」によって決定されます）。これにより、ビルドにどのような影響があるかについては、:doc:`relocatable-binaries`を参照してください。

GMX_USE_PLUGINS

動的プラグイン（例：VMDでサポートされているファイル形式）のサポートを有効にします。 デフォルト： OFF。

GMX_MPI

マルチノード間の並列処理のためのMPI（スレッドMPIではない）のサポートを有効にします。 デフォルトは「OFF」です。詳細については、インストールガイド を参照してください。

GMX_OPENMP

OpenMP のサポートを有効にします。デフォルトは ON です。

GMX_PREFER_STATIC_LIBS

外部ライブラリへの静的リンクを推奨します。デフォルトでは OFF に設定されますが、 GMX_BUILD_SHARED_EXE が無効になっている場合は、異なる設定が適用されます。

GMX_SIMD

利用する SIMD 命令セットを選択します。 デフォルトは ``Auto``（現在の CPU に最適なもの）です。 詳細については、インストールガイド を参照してください。

GMX_THREAD_MPI

ノード内での並列処理を可能にするために、スレッドとMPIのサポートを有効にします。 デフォルトでは「ON」に設定されます。

GMX_USE_RDTSCP

mdrun の実行時に、x86 CPU ベースのタイマーを使用するために、低レイテンシの RDTSCP 命令を使用します。非 x86 機器では無視されます。異種環境や非常に古い x86 CPU でコンパイルする場合は、 OFF に設定する必要がある場合があります。

GMX_USE_TNG

TNGライブラリを使用して軌跡の入出力を行います。デフォルトでは「ON」に設定されます。

GMX_USE_ITT

Intel ITTライブラリを使用して、Intelトレースツールで|Gromacs|タスクに注釈を付ける。デフォルトでは「OFF」に設定されます。oneAPIツールキットをロードする際に設定された VTUNE_PROFILER_DIR 環境変数を使用して、ライブラリを検索します。

GMX_USE_NVTX

NVTXライブラリを使用して、NVIDIAトレースツールで|Gromacs|タスクに注釈を付ける。デフォルトでは「OFF」に設定されます。ライブラリの場所は、``CUDA_HOME``環境変数から検索されます。

GMX_USE_ROCTX

AMD ROCm トレースツールで GROMACS タスクに注釈を付けるには、ROC-TXライブラリを使用します。 デフォルトでは OFF に設定されます。 ライブラリの場所は、ROCM_HOME 環境変数から検索されます。

GMX_VMD_PLUGIN_PATH

パスは、molfileの入出力用のVMDプラグインへのものです。 GMX_USE_PLUGINS が有効になっている場合にのみ使用されます。

all ターゲットに影響を与える変数

BUILD_TESTING

標準変数で、CTestによって作成され、すべてのテストを有効/無効化します。 デフォルトでは ON に設定されます。

GMX_BUILD_HELP

制御：manページとシェル補完の処理。可能な値：

「OFF」（リリースソース配布からのビルドの場合のデフォルト）

マニュアルページとシェル補完は、「all」ターゲットの一部として生成されず、ソースパッケージからコンパイルする場合にのみインストールされます。

AUTO (開発版からのビルドの場合のデフォルト)

シェル補完は、all ターゲットの一部として、gmx バイナリを実行することで生成されます。 失敗した場合、メッセージが表示されますが、ビルドは成功します。 マニュアルページは、man ターゲットを呼び出すことで手動で生成する必要があります。 マニュアルページとシェル補完は、正常に生成された場合にインストールされます。

ON

AUTO と同じように動作しますが、:file: gmx 実行可能ファイルの呼び出しに失敗した場合、ビルドも失敗します。

GMX_DEVELOPER_BUILD

もし ON に設定されている場合、all ターゲットには、Google Test を使用するテストバイナリも含まれます（ただし、:cmake:`GMX_BUILD_UNITTESTS が ON の場合）。また、webpage ターゲットには、PDF形式のリファレンスマニュアルも含まれます。さらに、:cmake:`GMX_COMPILER_WARNINGS と CMAKE_EXPORT_COMPILE_COMMANDS は常に有効になります。今後は、この変数によって制御される他の開発者向けの便利な機能（および、一般ユーザーにとっては不便な機能）を追加することも可能です。

GMX_CLANG_TIDY

clang-tidy は、静的コード分析と（一部の）検出された問題の自動修正に使用されます。 clang-tidy は簡単にインストールできます。 llvm のバイナリ package に含まれています。 18.0.* のみサポートされています。 他のバージョンでは、テストが実行されないか、誤った結果が表示される可能性があります。 各コミットに対して、GitLab CI で自動的に実行されます。 多くのチェックには、自動的に適用できる修正が含まれています。 実行するには、ビルドを次のコマンドで構成する必要があります。 cmake -DGMX_CLANG_TIDY=ON -DCMAKE_BUILD_TYPE=Debug。 任意の CMAKE_BUILD_TYPE でアサーションを有効にするもの（例：ASAN）を使用できます。 構成されたビルドでは、コンパイラと clang-tidy の両方をビルド時に実行します。 clang-tidy の実行可能ファイルの名前は、 -DCLANG_TIDY=... で設定し、完全なパスは -DCLANG_TIDY_EXE=... で設定できます。 検出された問題に対する自動修正を適用するには、clang-tidy を個別に実行する必要があります（ビルドの一部として clang-tidy を -fix-errors で実行すると、ヘッダーファイルが破損する可能性があります）。 特定のファイルを修正するには、 clang-tidy -fix-errors -header-filter '.*' {file} を実行します。 すべてのファイルを並行して修正するには、 run-clang-tidy.py -fix -header-filter '.*' '(?<!/selection/parser\.cpp|selection/scanner\.cpp)$' を実行します。 すべての変更されたファイルを修正するには、 run-clang-tidy.py -fix -header-filter '.*' $(git diff HEAD --name-only) を実行します。 run-clang-tidy.py スクリプトは、llvm の配布の share/clang/ サブフォルダにあります。 clang-tidy は、 compile_commands.json ファイルを見つける必要があります。 ビルドフォルダから実行するか、ソースフォルダへのシンボリックリンクを追加します。 GMX_ENABLE_CCACHE は clang-tidy とは連携しません。

特殊なターゲットに影響を与える変数

GMX_INSTALL_LEGACY_API

デフォルトでは OFF に設定されます。 ON に設定すると、ヘッダーが CMake ヘッダーの宛先フォルダにある gromacs/ にインストールされ、::gmx C++ 名前空間の使用を可能にします。これは、libgromacs ライブラリによってサポートされています。詳細は、「レガシー API <../doxygen/html-user/index.xhtml>」を参照してください。

GMX_INSTALL_NBLIB_API

「ON」に設定されている場合（デフォルト、およびWindows以外のプラットフォームでは：cmake:`BUILD_SHARED_LIBS`が有効になっている場合）、`libnb_gmx`と`nblib/`のヘッダーをビルドしてインストールします。詳細は：ref:`nblib`を参照してください。

GMXAPI

設定が ON (デフォルト、Windows以外のプラットフォームでは BUILD_SHARED_LIBS が有効な場合) の場合、追加の gmxapi C++ライブラリが構成され、gmxapi ヘッダーがインストールされます。 Doxygenが利用可能な場合、追加のビルドツリーターゲット gmxapi-cppdocs と gmxapi-cppdocs-dev を提供します。 また、gmxapi のCMake構成ファイルもエクスポートし、クライアントプロジェクトが GROMACS のインストールルートを検索して Gromacs::gmxapi CMakeターゲットをインポートできるようにします。

GMX_BUILD_MANUAL

もし ON に設定されている場合、LaTeX および関連する PDF マニュアルの依存関係の CMake 検出が実行され、マニュアルのビルド用の manual ターゲットが生成されます。 OFF (デフォルト) に設定されている場合、すべての検出がスキップされ、マニュアルはビルドできません。

GMX_BUILD_TARBALL

もし ON に設定した場合、バージョン文字列から -dev 接尾辞が削除され、およびその他のバージョン情報に関するロジックが調整され、このビルドから生成されるマニュアルページやその他のドキュメントが、ウェブページやソース配布パッケージで公開するために適したものになるようにします。 デフォルトでは OFF に設定されます。

GMX_BUILD_UNITTESTS

もし ON の場合、Google Test を使用してテストバイナリがビルドされます（別個の tests ターゲットとして、または all ターゲットの一部として、GMX_DEVELOPER_BUILD の設定に応じて）。 テストのビルドに必要なすべての依存関係（Google Test および Google Mock フレームワーク、および tinyxml2）は、src/external/ に含まれています。 BUILD_TESTING が ON の場合、デフォルトで ON に設定されます。

GMX_COMPACT_DOXYGEN

「ON」に設定すると、Doxygenの設定が変更され、大規模な依存関係グラフの生成を回避するため、Doxygenの実行が大幅に高速化され、ディスク使用量が削減されます。これは、ドキュメントの開発時にビルド時間を短縮するために一般的に使用されます。デフォルトでは「OFF」に設定されています。

REGRESSIONTEST_DOWNLOAD

もし ON に設定すると、CMake は回帰テストをダウンロードし、ローカルディレクトリに展開します。 REGRESSIONTEST_PATH は展開されたテストに設定されます。 ただし、これはビルド時にではなく、構成フェーズ中に行われます。 ダウンロードが完了すると、変数は自動的に OFF にリセットされ、繰り返しダウンロードを防ぎます。 必要に応じて ON に設定して、再度ダウンロードできます。 デフォルトでは OFF に設定されています。

REGRESSIONTEST_PATH

ソースツリー（:file:`gmxtest.pl`を含むディレクトリ）に存在する、回帰テストスイートへのパス。設定されている場合、CTestを使用して回帰テストを実行するためのテストが生成されます。デフォルトでは空です。

SOURCE_MD5SUM

生成されたHTMLドキュメントに、リリースtarボールのMD5ハッシュ値を設定します。これは、HTMLページのダウンロードセクションに挿入されます。

外部ライブラリ

特別なターゲット

「all」というデフォルトのターゲットに加えて、生成されたビルドシステムには、さまざまなタスクを実行するために明示的にビルドすることを目的とした、いくつかのカスタムターゲットがあります（これらのうち、一部は自動的に実行されることもあります）。これらのターゲットは、内部的にさまざまな他のターゲットも使用していますが、これらのターゲットは通常、直接呼び出すことは意図されていません。

確認

テストに必要なすべてのバイナリをビルドし、テストを実行します。 テストの種類によっては利用できない場合、ユーザーにその旨を通知します。 これは、通常のユーザーがテストを実行するための主要なターゲットです。 ユニットテスト を参照してください。

チェック・ソース

カスタムのPythonチェッカースクリプトを実行し、さまざまなソースレベルの問題をチェックします。 Doxygen XMLドキュメントと、一部のソースファイルの基本的な解析を使用します。 このターゲットは、CIの一部として使用されます。 現在のすべてのCMakeコードは、:file:`docs/doxygen/`にあります。 :doc:`gmxtree`を参照してください。

完了

コンパイルされた :file:`gmx`実行可能ファイルを起動し、シェルコマンドラインの補完定義を生成します。このターゲットは、:cmake:`GMX_BUILD_HELP`が ``OFF``でない場合にのみ追加され、デフォルトの ``all``ターゲットの一部として自動的に実行されます。詳細は、:cmake:`GMX_BUILD_HELP`を参照してください。すべてのCMakeコードは、:file:`src/programs/`にあります。

dep-graphs*

ビルドには、ソースファイルの依存関係グラフを作成するために、dot コマンド（graphviz）を使用します。すべての CMake コードは、docs/doxygen/ フォルダにあります。詳細は、スクリプトによるソースツリーのチェック を参照してください。

doxygen-*

Doxygenを実行してドキュメントを生成するターゲット。 doxygen-all ターゲットは、webpage ターゲットの一部として実行され、これはCIの一部として実行されます。 すべてのCMakeコードは、docs/doxygen/ にあります。詳細は、Doxygen の使用 を参照してください。

gmxapi-cppdocs

gmxapi 用の API ドキュメントを生成します。クライアントソフトウェアの作成者に役立ちます。ドキュメントは、ビルドディレクトリの docs/api-user に生成されます。

gmxapi-cppdocs-dev

gmxapiおよび|Gromacs|開発者向けのドキュメントを、`docs/api-dev`ディレクトリに抽出します。

ガイド

Sphinxを使用して、ソースパッケージのインストールのためのテキスト形式の INSTALL ファイルを生成します。このファイルは、docs/install-guide/text/ に生成され、CPack によってソースパッケージのルートディレクトリに配置されます。すべての CMake コードは、docs/ にあります。

マニュアル

Sphinxを使用してプログラムのドキュメント（マニュアルページ）を生成します。内部的には、コンパイルされた :file:`gmx`実行可能ファイルを起動して、Sphinxの入力ファイルを作成します。すべてのCMakeコードは :file:`docs/`にあります。マニュアルページのインストールに関する情報は、:cmake:`GMX_BUILD_HELP`を参照してください。

マニュアル

LaTeXを使用して、参照用のPDFマニュアルを生成します。すべてのCMakeコードは、:file:`docs/manual/`にあります。詳細は、:cmake:`GMX_BUILD_MANUAL`を参照してください。

package_source

標準的なターゲットで、CPackによって作成され、ソースパッケージをビルドします。このターゲットは、リリース用のソースパッケージを生成するために使用されます。

テスト

標準ターゲットは、CTestによって作成され、登録されているすべてのテストを実行します。ただし、このターゲットはテストの実行のみを行い、テストの実行ファイルを作成しないため、まずテストが最新であることを確認する必要があります。詳細は： ユニットテスト を参照してください。

テスト

テストに必要なすべてのバイナリをビルドします（ただし、``gmx``は含まれません）。詳細は： ユニットテスト を参照してください。

ウェブページ

集約対象であり、他のドキュメントターゲットを実行して、完全なHTML（およびリンクされた）ドキュメントを生成します。このターゲットは、CIの一部として使用されます。すべてのCMakeコードは：file:`docs/`にあります。

webpage-sphinx

Sphinxを使用して、HTMLドキュメント（この開発者向けガイドも含まれるウェブページのセット）の大部分を生成します。内部的には、コンパイルされた :file:`gmx`実行可能ファイルも実行し、Sphinx用の入力ファイルを生成します。すべてのCMakeコードは :file:`docs/`にあります。

ソースコードへの情報の伝達

ビルドシステムは、コンパイルに影響を与えるために、いくつかの異なるメカニズムを使用します。

  • 最も上位レベルでは、いくつかのCMakeオプションがどのファイルをコンパイルするかを選択します。

  • 一部のオプションは、コンパイラコマンドラインで -D やそれに相当する形式で指定することで、すべてのコンパイルユニットで利用できるようになります。ただし、コンパイラコマンドラインを管理しやすくするために、この方法を慎重に使用する必要があります。現在の設定は、次の場所で確認できます。

    git grep add_definitions

  • いくつかのヘッダーファイルは、CMakeの configure_file() を使用して生成され、目的のソースファイルに含められます。これらのファイルが存在していることが、コンパイルを成功させるための必要条件です。 #ifdef HAVE_CONFIG_H を使用して、定義が設定されていない場合に、これらのファイルがインクルードされないように保護するファイルはいくつかあります。これは、通常、メインのビルドシステム外でコンパイルされる可能性があるファイルで使用されます。

    buildinfo.h

    ビルド環境に関するさまざまな文字列を含み、主にログファイルへのバージョン情報出力や、必要に応じて使用されます。

    config.h

    ソースファイル内で条件付きコンパイルのための定義が含まれています。

    gmxpre-config.h

    含まれる：gmxpre.h は、ソースファイルの先頭に含める必要があります。正しく動作するためには、他のヘッダーを使用する前に必要な定義のみを含む必要があります。たとえば、システムヘッダーの動作に影響を与える定義はこのカテゴリに該当します。gmxpre.h の Doxygen ドキュメントを参照してください。

    上記のファイルは、common CMake ターゲットの INTERFACE_INCLUDE_DIR を通じて利用できます。 つまり、#include "config.h" を使用する場合は、必ず target_link_libraries(mymodule PRIVATE common) を実行してください。

    さらに、ビルドシステムによって以下のファイルが生成されます:

    baseversion-gen.cpp

    :file:`baseversion_gen.h の宣言の定義を提供し、バージョン情報の出力に使用します。内容は、Git のバージョン情報から生成するか、Git リポジトリからビルドされていない場合に、静的なバージョン情報から生成されます。