コードベースの概要

|Gromacs|リポジトリのルートディレクトリには、:file:`CMakeLists.txt`（CMakeビルドシステム用のルートファイル）、ビルドシステムをサポートするいくつかのファイル、および標準的な情報ファイル（:file:`README`など）のみが含まれています。 :file:`INSTALL`は、:file:`docs/install-guide/index.rst`からソースパッケージ用に生成されます。

その他のすべてのコンテンツは、次の上位レベルのディレクトリにあります:

admin/

開発者向けのさまざまなスクリプト、および一部のツールで使用される構成ファイルとスクリプトが含まれています。

api/

C++ API のインストール可能なコードが含まれています。

cmake/

このファイルには、CMake用のコードスニペットとモジュールが含まれています。ここに記載されている内容は、現在サポートされている最小バージョンよりも新しいCMakeのバージョンからコピーまたは適したものを含んでいます。Valgrind用のデフォルトの抑制ファイルも含まれています。ビルドシステムの詳細は、:doc:`build-system`を参照してください。

docs/

これには、すべてのドキュメント（ユーザー向けおよび開発者向けの両方）のビルドシステムロジックとソースコードが含まれています。一部のドキュメントは、:file:`src/`にあるソースコードから生成されます。詳細は、:ref:`dev-doc-layout`を参照してください。このディレクトリには、Doxygenドキュメントを使用して動作する、いくつかの開発者スクリプトも含まれています。

scripts/

GMXRCスクリプト、その他のインストール済みスクリプト、およびこれらのスクリプトのインストールに関するルールを含むテンプレートが含まれています。

share/

これには、share/ にインストールされるデータファイルが含まれています。これには、C++ 分析ツールの作成用テンプレートと、GROMACS で使用されるデータファイルが含まれています。

src/

これには、すべてのソースコードが含まれています。詳細は、:ref:`dev-source-layout`を参照してください。

tests/

一部の高レベルテストのビルドシステムロジックを含みます。 現在、レグレッションテストのビルドシステムロジックのみが含まれており、その他のテストは src/ にあります。

ソースコードの構造

サンプルコードは、Trajectory Analysis Framework の share/template/ フォルダにあります。

gmxapi Python パッケージとサンプル MD 拡張モジュールのコードは、python_packaging/ にあります。

api/ には、インストール可能な C++ API のコードが含まれており、これには、従来の gromacs ヘッダーと libgmxapi および (非)結合ライブラリ (NB-LIB) API の完全なソースコードが含まれています。

残りのソースコードは src/ ディレクトリ内にあります。

以下の図は、src/ ディレクトリにあるソースコードから構築されるコンポーネントの、高レベルな概要と、コードの構成を示しています。矢印は依存関係の方向を示しています。ビルドシステムの詳細については、ビルドシステムの概要 を参照してください。デフォルトの設定では、緑と白のコンポーネントはデフォルトのターゲットの一部として構築されます。灰色部分はテスト用であり、デフォルトでは「tests」ターゲットの一部としてのみ構築されますが、「GMX_DEVELOPER_BUILD」が「ON」になっている場合は、これらのコンポーネントもデフォルトのビルドターゲットに含まれます。テストに関する詳細は、ユニットテスト を参照してください。

ルートレベルには、ビルドシステムに関連するファイルがいくつかのみ含まれています。 実際のコードはすべて、サブディレクトリにあります。

src/gromacs/

このディレクトリにあるコードは、単一のライブラリである :file:`libgromacs`に統合されています。インストールされたヘッダーもこの階層内にあります。これはコードの主要部分であり、*モジュール*としてさらにサブディレクトリに整理されています。詳細は後述します。

src/programs/

|Gromacs|の実行可能ファイル「gmx」は、このディレクトリ内のコードからビルドされます。また、「gmx」によって呼び出される「mdrun」モジュールのドライバコードや、「gmx mdrun」の包括的なテストも、この場所で利用できます。

src/.../tests/

src/ の下には、さまざまなサブディレクトリがあり、それぞれに tests/ という名前のサブディレクトリが含まれています。 各サブディレクトリのコードは、テストバイナリにコンパイルされます。 また、一部のサブディレクトリには、複数の異なるフォルダからのテストバイナリにリンクされる共有テストコードがオブジェクトライブラリとして提供されています。詳細は：ユニットテスト を参照してください。

src/testutils/

Google Test テストの作成に必要な共有ユーティリティコードが含まれています。詳細は、ユニットテスト を参照してください。

src/external/

GROMACS が内部的に使用する、さまざまなライブラリおよびコンポーネントのバンドルされたソースコードが含まれています。 これらのディレクトリにあるすべてのコードは、独自のビルドルールを使用して、libgromacs に、または特定のケースではテストバイナリにビルドされます。 CMake の一部のオプションは、どのコードがビルドに含まれるかを変更します。 このディレクトリにあるコードがどのように使用されるかについての説明については、ビルドシステムの概要 を参照してください。

src/external/build-fftw/

このフォルダには、FFTWをダウンロードして`libgromacs`に組み込むためのビルドシステムコードが含まれています。

コンパイル時には、src/ ディレクトリへの検索パスが、明確なモジュール所有権を持たない多くのインターフェースに対して、legacy_modules CMake ターゲットによって設定されます。

一部のディレクトリ（src/external/ の下にあるものなど）は、コンパイルオプションによっては、含まれる可能性があります。

組織：src/gromacs/ 内

:file:`libgromacs`ライブラリは、:file:`src/gromacs/`にあるコードから構築されます。 繰り返しますが、上位レベルのディレクトリには、ライブラリのビルドとインストールに関するルールが含まれています。

コードはサブディレクトリに整理されています。これらのサブディレクトリは、このドキュメント全体で `:dfn:``modules``と表記されます。各モジュールは、特定のタスクを実行する一連のルーチン、または複数のタスクの集合で構成されます。多くのモジュールは、個別のCMakeターゲットで表現されており、`target_link_libraries()`<https://cmake.org/cmake/help/latest/command/target_link_libraries.html>を使用して、ヘッダーファイルとリンク可能なシンボルにアクセスできます。その他のモジュールは、ファイルシステムの階層のみで表現されており、そのソースファイルは、モノリシックな`libgromacs`CMakeターゲットに直接コンパイルされます。

モジュール：src/gromacs/ 内のモジュールは、公開インストールインターフェースの一部ではありません。ただし、従来インストールされていた一部のヘッダーは、更新された公開APIの仕様が完了するまで、api/legacy/include に移動されています（src/ 内には複製されていません）。これらのインターフェースは、ビルドツリー内の legacy_api CMake ターゲットにまとめられており、GMX_INSTALL_LEGACY_API=ON で構成されたインストールでは、IMPORTED ``Gromacs::libgromacs`` ターゲットを通じて利用できます。これらのモジュールは、インストールディレクトリ内の include/gromacs/ 以下の対応する階層にインストールされます。

歴史的に、ヘッダーファイルの先頭にあるコメントには、その可視性に関する注記が含まれていました。それは、public（インストール済み）、intra-library（ライブラリ内から使用可能）、またはintra-module/intra-file（モジュール/ファイル内から使用可能）のいずれかです。これらのコメントの多くは残っていますが、現在はメンテナンスされていません。

すべてのヘッダーは、インストールされたヘッダーが config.h に定義されている変数や、それ以外のヘッダーを参照することなく、自力でコンパイルされるようにする必要があります。 インストールされたヘッダーは config.h を含めることはできません。 循環的なインクルード依存関係は、この問題を回避するために必須です。 これを確実にするには、config.h を含む最初のヘッダーとして、すべてのヘッダーをあるソースファイルに含めることが最適です。

ライブラリ内のコードは、不要なヘッダーを含めるべきではありません。特に、ヘッダーには、型を前述するだけで十分な場合に、他のヘッダーを含めるべきではありません。ライブラリのソースファイル内では、そのファイルに必要な他のモジュールのヘッダーのみを含める必要があります。モジュールの CMakeLists.txt を確認して、target_link_libraries() を使用する必要があるかどうかを確認してください。多くのモジュールでは、モジュールの実装内でのみ使用される、公開インターフェースとプライベートインターフェースを区別しています。このような場合、ライブラリ内の他のモジュールで使用できる公開モジュールのヘッダーは、src/gromacs/modulename/include/gromacs/modulename サブディレクトリにあります。モジュールのプライベートヘッダー（ソースファイルと]) は、legacy_modules ターゲットなどを通じて、インクルードパスに漏れ出す可能性がありますが、他のモジュールで使用しないでください！

ファイル名に関する一般的なパターンについては、:doc:`naming`を参照してください。これらのパターンは、宣言を見つけるのに役立ちます。

テストと、それに必要なデータは、モジュールディレクトリの下にある tests/ サブディレクトリにあります。詳細は、ユニットテスト を参照してください。

ドキュメントの構成

すべてのドキュメント（この開発者向けガイドを含む）は、:file:`docs/`にあるソースファイルから生成されます。ただし、一部のコマンドラインヘルプは、コンパイルされた:file:`gmx`バイナリを実行することでソースコードから生成されます。ビルドシステムは、ドキュメントの作成に使用できるさまざまなカスタムターゲットを提供します。詳細は、:doc:`build-system`を参照してください。

docs/fragments/

このファイルには、さまざまな場所のドキュメント内で .. include:: メカニズムを使用して使用される reStructuredText の断片が含まれています。

ユーザーマニュアル

docs/install-guide/

このファイルには、ユーザードキュメントのインストールガイドセクションを構築するための reStructuredText ソースファイル、およびソースパッケージの INSTALL ファイルが含まれています。 ビルドルールは docs/CMakeLists.txt にあります。

docs/reference-manual/

HTMLおよびLaTeX用のリファレンスマニュアルを生成するための、reStructuredTextソースファイルが含まれています。

docs/manual/

ラテックスのヘルパーファイルを含み、リファレンスマニュアル（PDF）の作成に使用します。

docs/user-guide/

このファイルには、ユーザードキュメントのユーザーガイドセクションを構築するために使用される reStructuredText のソースファイルが含まれています。 ビルドルールは、次の場所にあります： docs/CMakeLists.txt。

docs/how-to/

このファイルには、ユーザー向けドキュメントの「使い方」セクションを構築するための reStructuredText ソースファイルが含まれています。

Unix のマニュアルページ

プログラムのドキュメントページは、`gmx`実行ファイルをコンパイルした後で実行し、その後、`gmx`が生成したreStructuredTextファイルに対してSphinxを実行することで生成されます。

マニュアルページのビルドルールは、次の場所にあります：:file:`docs/CMakeLists.txt。

開発者向けガイド

docs/dev-manual/

開発者向けマニュアルを構築するために使用される reStructuredText ソースファイルが含まれています。 ビルドルールは docs/CMakeLists.txt にあります。

開発者ガイドの構成は、ガイドの :dev guide の先頭ページで説明されています。

ドキュメント: Doxygen

docs/doxygen/

Doxygenドキュメントのビルドルールと概要コンテンツが含まれています。Doxygenドキュメントの構築と整理方法の詳細については、:doc:`doxygen`を参照してください。

Doxygenのドキュメントは、いくつかの異なる部分で構成されています。以下のリストを参考に、特定の種類のコンテンツをどこで探せばよいかを確認してください。ドキュメントは長期間にわたって作成されており、アプローチも進化してきたため、すべてのドキュメントがこれらのガイドラインに従っているわけではありませんが、これが目指している方向です。

ドキュメントページ

これらは主に概要内容を含んでおり、一般的なレベルからの導入から、個々のモジュールの特定の領域の説明までを網羅しています。これらは、コードや新しいコード領域に慣れるための出発点として最適です。これらのページは、メインページからのリンクや、関連する情報があるドキュメント内の他の場所からのクロスリンクを通じてアクセスできます。

モジュールに関するドキュメント

これらは主に技術的な内容を含んでおり、特定のモジュールの一般的な実装を説明し、モジュール内のクラス、関数などをリストアップしています。これらは、概念を説明するページを補完します。これらは、「モジュール」タブから、およびモジュールを構成するすべての個別のクラス、関数などからアクセスできます。

クラスのドキュメント

これらのドキュメントは、個々のクラスの使用方法を説明し、場合によっては、それに近いクラスの使用方法も説明しています。 必要に応じて（時間的な余裕がある場合）、より広範な概要は、別のページまたはモジュールドキュメントに記載されています。

ドキュメント

これらのドキュメントは、個々のメソッドについて説明しています。通常、クラスのドキュメントやその他の概要コンテンツには、さまざまなメソッドがどのように相互作用するかについての情報が記載されています。

ファイルと名前空間に関するドキュメント

これらは通常、リンクのプレースホルダーとしてのみ使用され、それ以外の情報はほとんど含まれていません。主な内容は、そのファイルで宣言されているクラスやその他のエンティティのリストです。