w64devkitのこの1年間

w64devkitのこの1年間 2026年9月20日 この1年間はw64devkitにとってエキサイティングなものでした。他のソフトウェアディストリビューションと同様に、w64devkitも決して完成することはありません。Peter0x44氏が共同メンテナーとして加わり、私が考えもしなかったようなアイデアでプロジェクトを良い、新しい方向へと推進してくれました。彼の改善の多くはアップストリームにも反映されており、w64devkitを使っていなくても恩恵を受けることができるでしょう。この1年間の様々な細かい点について触れたいと思います。 リリースセキュリティ 4月には、リリースパッケージングに署名が追加されたことを発表しました。現在、w64devkit内のすべてのEXEおよびDLLは私のキーでコード署名されています。私の署名キーは、約10万ホストで観測された数千のユニークな署名のおかげで良好な評判を確立しました。これは、リリースに約300のバイナリを含めるという嬉しい副産物です。ユーザーは最近、セキュリティソフトウェアに関する問題を減らすことができるはずです。MSYS2も私の署名ツールであるaas-signを採用しており、これは現在w64devkitのリリースに含まれています。ビルドはGitHub Actionsによって自動化され、私が新しいタグをプッシュしたときに（私だけが）トリガーされます。そのプロセスでコード署名が行われ、リリースが作成されます。リリースプロセスのすべてのステップは透明であり、リポジトリ内のソースから厳密に派生しています。どこにもカーテンの後ろに隠れて秘密の改ざんを許すような場所はありません。しかし、それだけではありません。リリース不変性を有効にしました。公開時に、リリース成果物はロックされ、私自身でさえ変更することはできません。これは、成果物リストの最後にリリース証明書が存在することで確認できます。プロジェクトに関わる誰もが後になって、古いリリースに何かをこっそり追加するというような不正行為をすることはできません。 ツールチェーンの変更 x64リリースは現在「マルチリブ」ツールチェーンです。つまり、x86リリースのスーパーセットとして、32ビットWindows用のプログラムをコンパイルできます。x86リリースの唯一の目的は、古いハードウェアまたは古いオペレーティングシステムでw64devkitを実行することです。x86リリースと同様に、デフォルトでWindows XPをターゲットとし、SSE2をサポートするCPU（つまり、少なくともPentium 4）が必要です。x86をターゲットにするには、コンパイルおよびリンク時に-m32を渡してください。あるいは、i686-w64-mingw32アーキテクチャトリプルでプレフィックスされたツールを使用する方が良いでしょう。後者は一般的に簡単です。なぜなら、異なるツールは異なるスイッチを必要とし、プレフィックス付きのツールはエイリアスであり、自動的に正しいことを行うからです。 $ x86_64-w64-mingw32-gcc -o hello64.exe hello.c $ i686-w64-mingw32-gcc -o hello32.exe hello.c マルチリブの追加は、予想よりも安価で簡単でした。これはPeter0x44氏のおかげです。すでにいくつかのプロジェクトで便利に使っています。以前は、GCCが他の必要なツールを見つけるために、w64devkitのbin/を$PATHに含める必要がありました。これはもはや必要なく、PATHを変更せずにスクリプトなどからpath/to/gcc.exeを呼び出すことができます。これには小さなGCCパッチが必要でした。 標準のCOFFオブジェクトフォーマットは最大65,535セクションをサポートします。このフォーマットが設計されたとき、これは十分すぎるほどだと思われたかもしれませんが、現代のC++プログラムは、特に多数のラムダ関数を使用するプログラムのデバッグビルドでは、簡単にそれを超えることがあります。C++プロジェクトが成長すると、bigobj COFFフォーマット（40億以上のセクションをサポート）を要求しないとビルドが失敗する閾値に達することがあります。これは煩わしく、ツールはこれを自動的に処理すべきです。数年前にBinutilsをパッチしてデフォルトでbigobjを生成するようにしたため、古い制限がビルドに影響することはありませんでした。ただし、Binutilsには標準COFFを要求するインターフェースがないため、必要に応じてダウングレードできません。なぜダウングレードが必要になるのでしょうか？公式のGoツールチェーン（gc）のような、より単純なリンカーと連携する場合です！一部のリンカーはbigobjを消費できません。また、ツールチェーンのオブジェクトフォーマットを自動検出する一部のビルド（例：当時のlibbacktrace）では、bigobjを知らないため、ビルドが壊れることがあります。理想的には、Binutilsは必要に応じてquietにbigobjにアップグレードすべきです。大きなプログラムだけがbigobjを使用します。単純なリンカーや検出スクリプトは標準COFFのみを扱います。さて、Peter0x44氏のおかげで、Binutilsは現在アップストリームでそのように動作しています！私のbigobjハックはもはや必要なくなり、cgoが再び動作するようになりました。 この1年間、w64devkitを可能な限り小さくすることへの重点を減らし、価値のある機能のためにインストールおよび配布サイズを増やすことをいとわないと決断しました。これは、静的ランタイムと計算負荷の高いツールのコンパイルオプションを-Osから-O2に切り替えることで具現化されています。すべてが少し大きくなり、少し速くなりました。標準ライブラリでかなりの時間を費やすプログラムは、少し速くなるでしょう。すでにパフォーマンスのために設計されたプログラムには違いはありません。 新ツール CMake、Ninja、そして新しいグラフィカルなCMakeデバッガがすべて含まれるようになりました。これらは少なくともWindows 7が必要です。CMakeのデフォルトはVisual Studioのインストールを探すことなので、CMakeをNinjaにデフォルト設定するようにパッチしました。それでも、Ninjaの代わりにGNU Makeを探すために-G MinGW Makefilesを指定することはできますが、推奨しません。Ninjaはより高速で堅牢です。 $ cmake -B build # Ninja用に設定 $ cmake --build build # Ninjaでビルド ccmake（Peter0x44氏の提案）も含まれており、CMakeの設定を検査および変更するためのTUIフロントエンドです。予想以上に役立っています。並列ビルドのために-jを渡すことができますが、代わりに環境変数を使用することを強くお勧めします。例えば、.profileで次のように設定します。 export CMAKE_BUILD_PARALLEL_LEVEL="$(nproc)" export CTEST_PARALLEL_LEVEL=$(nproc) はい、並列テストも可能です！もしそれが理にかなうのであれば、マルチコンフィグも推奨します。 $ cmake -B build -G 'Ninja Multi-Config' $ cmake --build build --config Debug $ cmake --build build --config Release これをデフォルトにすることも考えましたが、ビルドツリーのレイアウト（Debug/およびRelease/ディレクトリ）が変更され、現実世界のCMakeLists.txtの驚くべき割合がマルチコンフィグで壊れます。なぜなら、それらは正しく書かれていないからです。世界には、ほとんどのケースを静的に検出できる、優れたCMakeリンターが必要とされています。 それを補完するのがCcacheです。Peter0x44氏によるWindowsサポートを改善するための特別なパッチが適用されています。頻繁にブランチを切り替える場合、ccacheを使用すると（再）ビルドが速くなります。また、従来のCcacheのlib/ccache/ディレクトリも設定しました。これはw64devkit内のディレクトリで、$PATHに追加すると、すべてのビルドが透過的にCcacheでバックアップされます。典型的なLinuxディストリビューションでは、これは/usr/lib/ccache/になります。w64devkit.iniでパスタイプを使用して有効にすることもできます。 path type = minimal+ccache 私の場合、Ccacheは期待したほど役には立っていません。代わりにGit worktreesワークフローを採用しており、各ブランチは独自のビルドツリーで静止しています。 COMプログラミングを支援するため、キットには現在widlとuuidgenが含まれています。これらはMicrosoft MIDLのオープンソース代替であり、Interface Definition Language（IDL）ファイルを生成します。uuidgenは、私がMicrosoftツールをミニマリストに書き直したものです。 G. Berthiaume氏は、MakeビルドからJSON Compilation Databaseファイル（compile_commands.json）を抽出する新しいツール、make2compdbを作成しました。これはUnixフィルターとして動作します。 $ make -Bwn | make2compdb >compile_commands.json 私はrecycleツールを作成しました。これはファイルやフォルダをゴミ箱に送ります。フォルダの場合、これは通常rm -rfで削除するよりも高速です。他のシステムではtrashツールに相当します。私はファイルを削除することはほとんどなくなり、代わりにこのコマンドを使用してゴミ箱に入れ、ストレージセンサーが自動的に削除するまで数週間そこに置くようにしています。 数ヶ月前、古いパッチ管理ツールであるquiltの追加を発表しました。元のバージョンはWindowsをサポートしていないため、これはC++での完全な書き直しです。今やすべてのプラットフォームにQuiltがあるため、w64devkitのパッチはQuiltで管理されています。 インストーラー作成ツールであるNSISが現在含まれているため、独自のアプリケーションインストーラーをビルドできます。コマンドラインツールであるmakensisのみです。これも「マルチリブ」構成であり、x64 w64devkitは32ビットおよび64ビットのインストーラーを生成できます。（NSISを追加した動機は、私の代替alt-tabスイッチャーが、正しくインストールするためにインストーラーを必要としたことです。） Zstandardのzstd/unzstdが現在含まれています。なぜなら、ソースtarballはしばしば.tar.zst形式であるためです。