Zig向けにパッケージ化されたC/C++プロジェクト

All Your Codebase ...are belong to us、しかし喜んでお返しします！ この組織は何ですか？ 私たちはC/C++プロジェクトをZigのビルドシステム向けにパッケージ化しており、それにより皆様はそれらを容易に（そしてクロスコンパイルも！）確実にコンパイルできるようになります。これはZigコンパイラツールチェーンのユーザーに利便性を提供するだけでなく、C/C++プロジェクトのメンテナーに対して、プロジェクトのbuild.zigファイルがどのようなものかを示すことにもなります。 私はあなたがパッケージ化したプロジェクトのメンテナーですが、あなたの仕事はどのような価値を提供しますか？ 一般的な回答として、私たちはプロジェクトにZigへの依存関係を追加しますが、その代わりに以下の依存関係を削除します。 Make / GNUMake / CMake / autoconf / bashスクリプト / バッチスクリプト / powershellスクリプト: Zigは、サポートされているすべてのプラットフォームで動作し、これら他のツールができることすべてを実行できる完全なビルドシステムです。 Clang: Zigは完全なコンパイラツールチェーンであり、すべてのClangをバンドルしています。 システムパッケージマネージャー: Zigはパッケージマネージャーでもあり、必要であればZig用にパッケージ化された依存関係をダウンロードしてビルドできます。 Docker / CIマトリックスジョブ: ZigはC/C++/Zigコードをクロスコンパイルできるため、リリースはzig build releaseを実行するのと同じくらい簡単です。より一般的には、Zigはシステム全体の設定への依存関係をすべて削除しますが、必要に応じてオプトインする能力は残します。 私はあなたがパッケージ化したプロジェクトのメンテナーで、あなたの仕事が好きです。どのようにアップストリームできますか？ 私たちがパッケージ化したプロジェクトのメンテナーであり、ビルドパイプラインをアップグレードすることにした場合、私たちのリポジトリから必要なものをすべてアップストリームしていただくのは自由です。そうすることにした場合は、Issueを開いてお知らせください。そうすれば、私たちのリポジトリをアーカイブし、皆様をあなたのアップストリームに誘導できます。また、プロジェクトに正しく統合する方法について質問がある場合は、私たちのリポジトリのIssueセクションを自由に利用してください（例えば、二次ビルドステップを実装していない場合など）。 最後に注意点があります。リポジトリをアーカイブできるようにするためには、あなたのbuild.zigの統合は、私たちのバージョン以上のシステム依存関係を追加しないようにする必要があります。例えば、私たちのパッケージ化されたバージョンがallyourcodebase/zstd経由でzstdに依存できる場合、それへの依存を維持していただく（build.zigがアップストリームされるまで）か、System Library Integrationを利用してユーザーに選択肢を与えることをお願いしています。とはいえ、あなたが自由にビルドコードをアップストリームしていただくことはもちろん歓迎します。その場合でも、喜んでお手伝いしますが、私たちはダウンストリームフォークのメンテナンスを継続します。 あなたがパッケージ化したZigビルドシステム向けのC/C++プロジェクトはどのようになりますか？ 私たちは主に2つの戦略を使用します。 1. アップストリームプロジェクトを依存関係として追加し（build.zig.zon）、対応するbuild.zigスクリプトを私たちのリポジトリで定義します。 2. アップストリームプロジェクトをフォークし（オプションで他の無用なビルドスクリプトを削除）、Zigビルドスクリプトを追加し、元のプロジェクトに必要なパッチを適用します。後者の部分は通常必要ありませんが、一部のビルドステップは、設定スクリプトなどをZigビルドシステムで使いやすくするために、より適切にする必要がある場合があります。例えば、スクリプトが出力をハードコーディングするのではなく、出力パスを引数として受け取るようにする（これはZigビルドキャッシュと正しく統合するのに非常に役立ちます）といったことです。 あなたがアップストリームプロジェクトのメンテナーである場合、(1)はあなたが2つのファイル（build.zig、build.zig.zon）のみを必要とすることを明確に示しますが、他のすべてのビルドスクリプトをクリーンアップし、上記の通りZigビルドスクリプトを改善するのはあなたの責任です。一方、(2)は、作業をアップストリームする際に少し注意が必要ですが、すべてがより徹底的に行われています（ただし、Zigビルドスクリプトファイルのみを取得し、アップストリームプロジェクトへの統合方法を手動でレビューするオプションもあります）。 私はZigユーザーで、リポジトリに貢献したいのですが、どうすればよいですか？ kristoffにpingして、組織に追加してもらうように依頼してください。リポジトリに貢献するための基本的なルールをいくつか紹介します。 あなたのリポジトリには、あなたのコード（新しいbuild.zigファイル）に対するライセンスが必要です。そして、それは元のプロジェクトのライセンスと同等以上に寛容でなければなりません（シンプルにするためにMITを使用すれば間違いありません）。 あなたのリポジトリは、Zig固有の追加のもの（例えばバインディング）を追加せずに、元のC/C++プロジェクトをパッケージ化する必要があります。バインディングは、あなた自身が直接所有する別のリポジトリに配置しても構いません。 最新のタグ付きZigバージョンをターゲットにする必要があります。 元のプロジェクトをポートする際は、最初の戦略（build.zig + クリーンなtarball）を使用し、次の戦略（プロジェクト全体のフォーク）に切り替えるのは、以下の場合のみとします。 元のソースコードをビルドできるようにパッチを適用する必要がある場合。 他のすべてのビルドスクリプトをクリーンアップし、ビルドプロセスの途中段階の処理を改善する場合。この最後の点の例としては、プロジェクト固有のビルドツール（アセット処理ツール、画像オプティマイザーなど）が、出力パスをハードコーディングしている（通常はカレントディレクトリ）のを、Zigビルド（エコ）システムにより良い市民として機能するように、出力引数を受け取るように変更することが挙げられます。 Zigビルドが成功することを保証するCIジョブを追加する必要があります。例えば、allyourcodebase/AFLplusplusからスクリプトをコピーできます。 アップストリームプロジェクトの新しいバージョンがリリースされたときに、ビルドスクリプトを更新するための、時折のメンテナンスタスクを行うことに興味がある必要があります。 上記のチェックリストが完了したら、リポジトリに適切なタグを設定して、発見しやすくしてください（例: zig, zig-package）。