Zig: 全てのパッケージ管理機能がコンパイラからビルドシステムへ移行

Devlog このページには、mainブランチのZigにおける最近の変更点がまとめられています。RSSフィードとしても利用可能です。このページには2026年のエントリが含まれています。他の年はDevlogアーカイブページで利用可能です。 2026年6月30日 全てのパッケージ管理機能がコンパイラからビルドシステムへ移行 著者: Andrew Kelley ユーザーのbuild.zigスクリプトとビルドシステム自体のための別個のプロセスが存在するようになった今、パッケージ管理ロジックが存在する場所としてそれが理にかなっています。 私はこれらのサブコマンドをmakerプロセスに移動しました: zig build zig fetch zig init zig libc これにより、かつてコンパイラ実行可能ファイルに含まれていた機能の大部分が、ソース形式で出荷されるようになりました。これには以下が含まれます: パッケージ取得ロジック HTTPクライアントとネットワーキング TLS（Transport Layer Security）および関連する暗号化 Gitプロトコル xz、gzip、zstd、flate、zip build.zig.zonファイルの解析、検証、その他の処理 その結果、この機能はコンパイラを再ビルドせずにパッチを適用できるようになり、ユーザーや貢献者がいじりやすくなりました。 さらに、zigにおけるパッケージ管理は、maker実行可能ファイルがReleaseSafeモードでコンパイルされているため、ネットワーキングを行う際に安全チェックが有効になりました。加えて、ネットワーキングやファイルハッシュに使用される全ての暗号化は、ホストで利用可能な特別なCPU命令を利用できるようになりました。これは、ソフトウェア配布時に通常依存するには稀すぎるものまで含みます。私たちは、AOTのケーキを食べながら、JITのケーキも食べることができるのです！ 私がこれを始めた当初の動機は、maker/configurerプロセスの分離が--build-runnerオーバーライドフラグに破壊的な変更を加えた後にZLSをアンブロックするために、ビルドサーバープロトコルを公開することに関連していました。 当初、プロセスツリーは次のようになっていました: zig build（zigコンパイラ＋パッケージマネージャー） └─ builder（ユーザーのbuild.zigロジック＋ビルドシステム実装） プロセスの分離変更により、代わりに次のようになりました: zig build（zigコンパイラ＋パッケージマネージャー） ├─ configurer（ユーザーのbuild.zigロジック） └─ maker（ビルドシステム） この時点で、ファイルの監視とソースコードの変更時の再ビルドを行う、長時間実行されるzig build --watchプロセスを考えてみてください。build.zigへの変更が検出された場合、またはそのロジックの実行中に観察されたファイルが変更された場合、configurerを再実行する必要があることを意味します。これは、zig buildがパッケージ管理ロジックを繰り返す機会を与えるためにmakerプロセスが終了する必要があることを意味します。 今、このdevlogエントリで説明されている変更の後、次のようになります: zig build（zigコンパイラ） └─ maker（ビルドシステム＋パッケージマネージャー） └─ configurer（ユーザーのbuild.zigロジック） したがって、設定を再実行する必要がある場合、makerプロセスは親プロセスであるため、兄弟プロセスではなく存続できます。今後のビルドサーバーに関しては、サーバーが終了してクライアントが再接続する必要があるという厄介な状況を回避できることを意味します。単にクライアントに設定変更を通知するだけです。 これはほぼ完全に非破壊的な変更ですが、いくつかの観測可能な違いがあります: Zig実行可能バイナリサイズ: 14.1 MiBから13.5 MiBへ4%縮小（LLVMなし、ReleaseSmall） --maker-optフラグはZIG_DEBUG_MAKER環境変数に置き換えられました --zig-lib-dirフラグはZIG_LIB_DIR環境変数に置き換えられました この変更セットのフォローアップ課題は、Zig 0.17.0をタグ付けするまでの主なブロッカーです: ビルドサーバープロトコルMVP（ZLSをアンブロックするために必要） ビルドスクリプト自体のパス依存関係を追加する概念の導入 zig build --watchがビルドスクリプトの変更を検出し、自身を再実行するようにする 異なるカレントワーキングディレクトリがビルドスクリプトのキャッシュミスを引き起こす 7月には2つのカンファレンスが予定されており、講演の準備をする必要があるため、現実的に考えると、8月上旬までにはこれらを完了する時間はないと思います。もちろん、貢献は大歓迎です。 ZLSチームのTechatrix氏には、ビルドサーバープロトコルについて連絡を取り、協力してくれたことに大変感謝しています！彼らはスポンサーを募集しています。 2026年6月26日 SPIR-Vバックエンドの進捗状況 著者: Ali Cheraghi カバーすべきことはかなりあります。最近のコンパイラ変更の後、SPIR-Vバックエンドはいくつかの場所でビットが腐敗していたため、私は過去数週間かけてそれをより良い状態に引き戻す作業を行いました。 @SpirvType SPIR-Vには、Zigの型システムで表現できなかったいくつかの型があります。新しい@SpirvType組み込みは、シェーダーの記述における最も長年のブロッカーに対処するために導入されました。背景を追跡するには、#20550、#23326、および#35461を参照してください。 const Sampler = @SpirvType(.sampler); const Image = @SpirvType(.{ .image = .{ .usage = .{ .sampled = u32 }, .format = .unknown, .dim = .@