パッケージ間のビルド依存関係を宣言して文書化するツールチェーンにとらわれない方法を誰かが推奨できますか？
私は現在、すぐに辞めるプロジェクト（博士号取得）を手元に置いており、誰がいつ誰に知っているかはまだわかりませんが、取り上げられる可能性があるため、理解できる形で残す必要があります。
したがって、それがどのように構築されているかについて、少なくともいくつかのドキュメントを残したいと思います。プロジェクトは7つのパッケージで構成されており、各パッケージは独立したソースコードパッケージであり、そのコンパイルは他のパッケージのライブラリとヘッダーのみに依存します。ビルドプロセス全体はオープンソース標準を中心に展開されます。つまり、各プロジェクトはautoconfとautomakeによってビルドされ、Debian化され、パッケージ間の依存関係がDebianパッケージで宣言され、configureスクリプトでチェックされます。
ただし、これは非常に一般的な問題を指定する非常に具体的な方法のように感じます。次のメンテナーは、autoconfやDebianについて何も知らないWindowsGUIを使ってソフトウェアをビルドしたいと思うでしょう。この場合、さまざまなINSTALLファイルのコメントやDebianファイルのBuild-Depends/Depends宣言よりも厳密なドキュメントを残したいと思います。
パッケージングとビルド順序を文書化するためのツールチェーンにとらわれない確立された言語または標準はありますか？実際のビルドシステム仕様（Debian Build-Dependsなど）をそこから生成できる場合はボーナスポイント。
Graphvizは、ドキュメント用のグラフィック出力を生成する目的に加えて、非常に読みやすく、編集可能です。長年にわたるいくつかの異なるプロジェクトで、graphviz出力を生成する、または単純にdepを手動で入力するいくつかの簡単なツールを作成しました。その結果、プロジェクトマネージャーと上司はすべて、図が非常に役立つと感じたため、コピーを印刷してホワイトボードにテープで貼り付けました。
これらの1つは、大規模なgnu/linux組み込みシステムプロジェクトの依存関係チェーン全体に対するものであり、ツールチェーン、binutils、gplパッケージなどの間に数十の依存関係がありました。図が大きくなりすぎて、法定サイズの紙に収まりませんでした。 。
（正直なところ、これはgnu/linuxを選択するための莫大な隠れたコストです：パッケージを互いに統合しない作者からの数十の独立したパッケージ。netbsdの場合、「システム」は1つのベンダーからの1つの製品になります。 netbsdリリース。）