build2-package は何をしますか？
ROOTの解決
HEREを、このSKILL.mdを含むディレクトリ（システムコンテキストからの絶対パス）とします。
ROOTはbuild2スキルツリーです。以下の候補から、guides/packaging-guide-summary.mdが存在する最初のものを使用します。
HERE/../build2（兄弟レイアウト：このディレクトリがbuild2スキルの隣にある場合。ユーザーレベルのスキルディレクトリへのコピーを含む）HERE/../..（ネストレイアウト：このディレクトリがbuild2スキルのskills/サブディレクトリの下にある場合）
どちらも存在しない場合は停止します。
以降のすべてのread_fileパスは${ROOT}/...です。
このファイルが手順です。${ROOT}/guides/および${ROOT}/HOWTO/の下にあるパッケージングガイドが、各ステップの実行方法の真実の情報源です。レイアウト、bdep newの呼び出し、ブランチ名、公開シーケンスを勝手に発明しないでください。
外部アクションには明示的な承認が必要です
このスキルは、実際に公開可能なパッケージを作成し、最終的に公開します。自身のローカルワーキングツリーの外に見えるようになるものは、自動的には発生しません。これには以下が含まれます：GitHub上でのリポジトリ作成、git push（ブランチまたはタグ）、GitHub上でのリポジトリの転送または名前変更、プルリクエストのオープンまたはマージ、bdep ciの実行、およびbdep publishの実行。
/build2-package（または/build2 package）の実行は、これらのいずれかの承認にはなりません。また、これらのいずれかが発生するゲートに到達したとしても同様です。この実行で初めてこれらのいずれかを実行する前に、停止し、今まさに何が発生しようとしているのか（コマンド、および外部に見えるようになるもの）を正確に述べ、その特定のアクションに対するユーザーの明示的な許可を待ちます。あるアクションに対する承認は、後続のアクションには引き継がれません。毎回再度確認してください。デフォルトの前提：ユーザーがそのステップを明示的に要求しない限り、これらのいずれも発生しません。
その他すべて（ローカルコミット、ブランチ作成、ファイル編集、ローカルビルドとテスト、読み取り専用のクローンまたはフェッチ）は、質問なしで進行します。
ハードルール
これらはオプションではありません。1つでも違反すると、実行は失敗とみなされます。
buildfileをゼロから決して書かないでください。常にbdep newから始めてください。このワークフローでは${ROOT}/scripts/new-package.shを使用しないでください。- 公開時のfast-forwardマージで
reviewをマージするまで、最初のbdep new --type empty,third-partyコミット以降はmainに触らないでください。 - 依存関係をバンドル（ベンダリング）しないでください。
dependsとしてアンバンドルしてください。 - ルート
buildfileにメインのlib{}/exe{}ターゲットを決して置かないでください。 - アップストリームがコンパイルモードを出荷している場合、ライブラリをヘッダオンリーにしないでください。
- ソース配布レシピ（
b dist、次に展開されたアーカイブ内でconfigure、update、test、clean）を決してスキップしないでください。bdep ciがグリーンであるだけでは不十分です。 - 生成された
depends: * build2/depends: * bpkg行を低くしないでください。 - アップストリームのタグ、ライセンス、またはパブリックヘッダのインクルードスキームを推測しないでください。ツリー内またはフェッチされたページにない場合は、停止して質問してください。
- 論理的なパッケージングステップごとに1つのgitコミット（または密接に関連するグループ）。ツリーが正確に1つの
bdep new呼び出しであるコミットは、そのコマンドラインをコミットメッセージとして使用し、それ以外は何も使用しません。1つのアップストリームファイルに対して.orig/.patchオーバーレイペアを作成するコミットは、Patch <filename>: <reason>（オプションで、自明でないパッチの場合は<details>本文）をメッセージとして使用します。packaging-guide-antipatterns.mdを参照してください。 - ローカルテスト、インストール済みケーステスト、配布テスト、およびCIがグリーンになるまで、
reviewをmainにマージしないでください。bdep releaseを実行しないでください。bdep publishを実行しないでください。 - すべてのディレクトリレベルのシンボリックリンク（プレーンファイルのシンボリックリンクではない）には、そのパッケージ自身の
<pkg>/.gitattributes（新しいファイル、bdep new --packageは生成しません）に、一致するsymlink=dirエントリが必要です。シンボリックリンクを追加したのと同じコミットで行います。find <pkg>/ -type l -exec test -d {} \; -printで確認し、すべてのヒットを<pkg>/.gitattributesと照合してください。gitはシンボリックリンクのタイプを記録せず、チェックアウト時に常にファイルシンボリックリンクを再作成するため、これをスキップするとWindowsチェックアウトでパッケージが壊れます。 - パッケージングプロセス自体、以前の動作しなかったアプローチ、または途中の事故を説明するコメントやREADMEノートを決して残さないでください。コメントとREADMEは最終状態のみを反映します（packaging-guide-antipatterns.mdの「日記形式のコメントやメモを残さない」を参照）。
- その特定のアクションに対するユーザーの明示的な承認なしに、リポジトリを作成したり、GitHub上でプッシュ、転送、名前変更を行ったり、プルリクエストをオープンまたはマージしたり、
bdep ciを実行したり、bdep publishを実行したりしないでください。承認はその時点で与えられる必要があります（上記の「外部アクションには明示的な承認が必要です」を参照）。デフォルトでは、これらのいずれも発生しません。
必須の読み物（今回、書き込み前）
リポジトリを作成したり、buildfileを編集したり、公開したりする前に、以下のファイルをread_fileで全文読んでください。流し読みはしないでください。
${ROOT}/guides/packaging-guide-summary.md${ROOT}/guides/packaging-guide-testing.md${ROOT}/guides/packaging-guide-antipatterns.md${ROOT}/HOWTO/package-naming.md
その後、このファイルの最後にあるマップからオンデマンドでロードしてください。このファイルで名前が挙げられているガイドを、記憶で代用しないでください。
チェックリストドキュメントに照らして随時再確認する
完全なパッケージングストレッチ（Gate A〜K、またはnew-version/revision実行）は、単一のコンテキストウィンドウが保持できるよりもはるかに多くのターンに及ぶ可能性があります。以前のターン（上記の必須の読み物を含む）は、後のゲートに到達する頃にはすでに要約されてなくなっている可能性があります。最初にガイドを一度読んだからといって、そのルールがまだコンテキスト内にあるとは限りません。それらについて会話の記憶に依存しないでください。
少なくともゲートごとに1回、およびGate K（公開時）の直前に、以下のチェックリスト形式のドキュメントに対してツリーの現在の状態を再度開いて再確認してください。
${ROOT}/guides/packaging-guide-antipatterns.md：やってはいけないこと（手書きのbuildfile、パッケージ内でのアップストリーム修正、変更されたアップストリームレイアウト、コンパイルモードがあるのにヘッダオンリー、バンドルされた依存関係、ルートbuildfile内のメインターゲット、範囲が広すぎるリビジョン、不適切なヘッダインクルード、アドホックパッチ、日記形式のコメントやメモ）。${ROOT}/guides/packaging-guide-review.md：cppget.orgのレビュアーが適用するのと同じチェックリスト。公開前にツリーをこれに照らして自己チェックし、実際のレビューで見つからないようにしてください。${ROOT}/HOWTO/third-party-private-headers.md：プライベートヘッダはインストールツリーに到達してはなりません。${ROOT}/HOWTO/buildfile-compile-options.md：どのコンパイル/リンクオプションがローカルか、エクスポートされるか。${ROOT}/HOWTO/package-naming.md：Gate Eで行われた命名の決定。後半で発見された名前変更はコストがかかります。${ROOT}/guides/packaging-guide-summary.mdステップ5：すべてのパッケージ内のすべてのディレクトリシンボリックリンクには、そのパッケージ自身の<pkg>/.gitattributesにsymlink=dirエントリがあります（ハードルール11）。
ツリーがこれらのいずれかと一致しなくなった場合は、ずれを先送りにするのではなく、次のゲートに進む前に修正してください。
引数
$ARGUMENTSは、/build2-package（または/build2 package）の後の呼び出しテキストです。順番に解析してください。最初に一致したルールが優先されます。
| 最初のトークン | モード |
|---|---|
| 空 / 省略 | cwdがすでにパッケージングリポジトリでない場合はnew、そうでなければcontinue |
new | 初期パッケージングストレッチ |
new-version | 最初の公開後の新しいアップストリームバージョン |
revision | パッケージリビジョン（X.Y.Z+R） |
continue | cwdで進行中のストレッチを再開 |
| その他 | git URLまたはowner/repoのように見える場合は、そのアップストリームでnewとして扱います。そうでなければ質問します。 |
残りのトークン：オプションの<upstream-url>とオプションの<tag-or-version>。いずれかが欠落しており、モードに必要な場合は質問してください。発明しないでください。
最初の書き込みの前に、選択したモードをユーザーに報告してください。
モード: continue
cwd（およびそのgit履歴）を検査し、以下のマッチングモードの最初の不完全なゲートから再開します。証拠は会話の要約よりも優先されます。
| 証拠 | 再開位置 |
|---|---|
.gitがない、またはbdep new --type empty,third-partyの最初のコミットがない | 最初からnew |
最初のコミットは存在するが、reviewブランチがない | reviewを作成し、newを続行 |
review上にいるが、upstream/サブモジュールがない | アップストリームを追加 |
upstream/は存在するが、パッケージディレクトリがない / bdep new --packageがない | パッケージ構造 |
| パッケージスキャフォールドは存在するが、テストまたはCIがグリーンではない | テスト |
テストはグリーンだが、reviewがmainにマージされていない | 公開時のマージ |
マージ後にmain上にいるが、vX.Y.Zタグがない | リリースしてから公開 |
| すでに公開されており、ユーザーが新しいアップストリームを要求した | new-version |
| すでに公開されており、ユーザーがパッケージング修正を要求した | revision |
リポジトリがmain上にあり、パッケージングコミットがreview上にあるべきだった場合、停止してください。それはプロセスエラーです。公開された履歴を書き換えないでください。回復方法をユーザーに尋ねてください。
モード: new（初期ストレッチ）
${ROOT}/guides/packaging-guide-summary.mdのチェックリストと${ROOT}/guides/packaging-guide-testing.mdのステップ8〜10に従ってください。以下の番号付きゲートは、スキップしたり順序を変更したりしてはいけないものです。
Gate A: 既存の作業
以下の4つすべてをこの順序で検索し、ヒットを報告してください。
https://cppget.org/?advanced-searchhttps://queue.cppget.orghttps://github.com/build2-packaginghttps://github.com/build2-packaging/WISHLIST
リポジトリまたは公開されたパッケージがすでに存在する場合は、停止し、重複を開始する代わりにその作業に参加するかどうかを尋ねてください（continue / new-version / revision）。
Gate B: 空のリポジトリと最初のコミット
このゲートの外部アクションの前に停止し、明示的な承認を得てください： GitHubリポジトリの作成と初期コミットのプッシュ。最初にローカルスキャフォールド（bdep new、git add、git commit）を実行して、何がプッシュされようとしているかを示すのに役立つ場合は実行してください。ただし、ユーザーが実行を許可するまで、リモートリポジトリを作成したり、git pushを実行したりしないでください。
ユーザーの個人ワークスペースに空のパブリックgitリポジトリを作成します。説明：build2 package for <name>。SSHでクローンします。README、ライセンス、GitHub生成ファイルはありません。
bdep new --type empty,third-party
git add .
git commit -m "bdep new --type empty,third-party"
git push -u origin main
続行する前に確認：
git rev-list --max-parents=0 HEADがこのコミットであること。git show --stat --format=%s HEADのメッセージが正確にbdep new --type empty,third-partyであること。- ツリーがそのコマンドによって生成されたファイルのみであること。
そのコミットに余分なファイルや手動編集がある場合は、リセットしてやり直してください。レビュープロセスはこれに依存しています。
Gate C: reviewブランチ
git checkout -b review
このストレッチの以降のすべてのコミットはreview上に留まります。git checkout mainを実行しないでください。マージしないでください。リリースしないでください。公開しないでください。
Gate D: アップストリームサブモジュール
git submodule add https://github.com/<upstream>/<repo>.git upstream
https://のみを使用してください。リリースコミット（タグ）をチェックアウトします。コミット：Add upstream submodule, <tag>。
Gate E: 名前とレイアウト
必要に応じて${ROOT}/HOWTO/package-naming.mdをもう一度読んでください。決定し、パッケージを生成する前にその決定を書き留めてください。
- Gitリポジトリ名：アップストリームのケース、
build2-プレフィックスなし、-packageサフィックスなし。 project:およびproject =：小文字。ただし、混合ケースがアップストリームの識別子である場合を除く（Qtは文書化された例外です）。- パッケージ
name:：ライブラリの場合はlibプレフィックス。ただし、Debianとアップストリームの両方で実行可能ファイルの競合が不可能な場合を除く。 - ライブラリと実行可能ファイルを別々のパッケージに分割します。
- パブリックヘッダのインクルードスキーム（サブディレクトリプレフィックス vs ファイル名プレフィックス）。
- 結合された
include//src/vs 分割。
可能な限りアップストリームレイアウトに近づけてください。
Gate F: プリシードしてからbdep new --package
パッケージディレクトリを作成します。存在するアップストリームのメタファイル（README.md、LICENSE / 同等、NEWS / CHANGES / ChangeLog）のみをシンボリックリンクします。それを単独でコミットします。次に：
bdep new --package --lang ... --type lib,...,third-party <name>
手動でスキャフォールドを編集するのではなく、削除して再実行することで反復し、レイアウトが一致するまで続けます。third-partyサブオプションは必須です。正確なコマンドラインをメッセージとしてコミットします。
チェンジログのベース名が認識された名前でない場合は、後で手動でchanges-file:を設定します。${ROOT}/HOWTO/package-changes-file.mdを参照してください。
Gate G: バージョン、マニフェスト、依存関係
- バージョンは
bdep release --no-openまでX.Y.Z-a.0.zのままです。 summary：70文字未満、曖昧な表現なし、末尾のピリオドなし。- 付随する
-tests/-examples/-benchmarks：メインのサマリーをコピーし、（tests）（または対応する種類）を追加します。書き換えないでください。${ROOT}/HOWTO/tests-extra-dependencies.mdを参照してください。 license:はSPDX（またはother:）です。${ROOT}/guides/packaging-license.mdを参照してください。pkg.cppget.orgの前提条件をコメント解除します。すべての依存関係を含む、最も安定性の低いセクションを使用してください。長期保存されるrepositories.manifestにqueue.cppget.orgを残さないでください。dependsの編集後にbdep sync -aを実行します。- このライブラリのパブリックヘッダにあるインターフェースヘッダは
intf_libsに配置します。その他はすべてimpl_libsに配置します。
Gate H: ソースとbuildfileの作成
buildfileに触れる前に、パッケージツリーにアップストリームソースを配置します。まず個々のヘッダ/ソースファイルをシンボリックリンクし、多くの個別のシンボリックリンクを節約できる場合にのみサブディレクトリ全体をシンボリックリンクします（buildfile-in-prefixレイアウトが必要です。packaging-guide-antipatterns.mdを参照）。${ROOT}/guides/packaging-guide-summary.mdのステップ5の実際の例に従ってください。
必須： 追加したディレクトリシンボリックリンクごとに、同じコミットでそのパッケージ自身の<pkg>/.gitattributesに一致するsymlink=dirエントリを追加します（ファイルがまだ存在しない場合は作成します）。find <pkg>/ -type l -exec test -d {} \; -printで確認し、すべてのヒットを照合してください。これはハードルール11です。スキップするとWindowsチェックアウトでパッケージが壊れます。buildfileを調整する前に、シンボリックリンク（および.gitattributes）をコミットして、ロールバックを容易にします。
その後、生成されたファイルのみを調整します。生成された構造とコメントを保持します。
オンデマンドでロード：
- ヘッダ / プライベートヘッダ：
${ROOT}/HOWTO/third-party-private-headers.md - SONAME / 出力名：
${ROO...
（以降、原文が途中で切れています）