【実務・中級編】MSYS2のPacmanパッケージを自作する：PKGBUILDの書き方と独自のバイナリ配布術 – 実行環境・ランタイム・コンパイラ生産性向上バイブル

こんにちは。テックリードの私だ。

開発現場でWindowsをメインの作業環境として強制される、あるいはクロスプラットフォームなC/C++プロジェクトを扱う際、頭を悩ませる最大のボトルネックは何か？ そう、依存ライブラリの管理とビルドの断絶だ。

「このサードパーティ製ライブラリ、公式のMSYS2（Pacman）リポジトリにないぞ……？」

ここで絶望して、ソースコードを直接クローンし、手動で `CMake && make && make install` を叩いて `/usr/local` の闇に葬り去るエンジニアが後を絶たない。しかし、それをやった瞬間に君の環境は「二度と再現できない汚染された環境」へと堕ちる。バージョンアップの追従もできなければ、クリーンビルド時の依存関係地獄から抜け出せなくなる。

プロの開発者であれば、すべてのアーティファクトはパッケージマネージャの管理下に置くべきだ。MSYS2におけるPacmanは、Arch Linuxの血を受け継いだ最強のパッケージ管理システムである。今回は、公式に存在しないライブラリを自前の `PKGBUILD` でパッケージングし、ローカルリポジトリとしてチーム共有・管理するプロフェッショナルなワークフローを完全伝授する。

—

1. なぜPKGBUILDを書くべきなのか？（アーキテクチャの理解）

MSYS2の基盤であるPacmanは、単なるファイルのコピー屋ではない。各パッケージはメタデータ（依存関係、バージョン、インストールファイルリストなど）を含んだ `.pkg.tar.zst` というアーカイブであり、システム内のすべてのファイルがデータベースによって厳密にトラッキングされている。

手動ビルドによる `make install` を避けるべき理由は以下の通りだ：

  • 追跡不可能性: どのファイルがどのライブラリによって配置されたか分からなくなり、アンインストールやクリーンアップが不可能になる。
  • マルチABI（UCRT64 / MINGW64）の崩壊: MSYS2には複数の実行環境（`ucrt64`, `clang64` など）が存在し、それぞれリンクすべきランタイムやパスが異なる。手動ビルドではこれを正確に切り分けるのが困難。
  • 再現性の欠如: 開発マシンが変わるたびに同じビルド手順を人間が手で行うのは、CI/CDの思想に反する。

`PKGBUILD` は、ソースの取得、パッチの適用、ビルド、パッケージングまでの全ライフサイクルをサンドボックス環境で自動化するシェルスクリプトである。これを制することが、Windows上の低レイヤ開発における生産性を極限まで高める鍵となる。

—

2. 実践：PKGBUILDの書き方とベストプラクティス

今回は例として、公式リポジトリにはない架空の高速C++シリアライゼーションライブラリ `libfastser` をパッケージングするシナリオを想定する。

作業ディレクトリ（例: `~/packages/libfastser`）を作成し、その中に `PKGBUILD` という名前で以下のファイルを配置する。

実用的な `PKGBUILD` の構成例

Maintainer: Your Name
ターゲットとするアーキテクチャ（UCRT64環境を前提とする）
pkgname=mingw-w64-ucrt64-libfastser
pkgver=1.2.0
pkgrel=1
pkgdesc=”A high-performance C++ serialization library (custom packaged)”
arch=(‘any’)
url=”https://github.com/example/libfastser”
license=(‘MIT’)
依存する他のPacmanパッケージ。ビルド時(-devel)と実行時を意識する
depends=(‘mingw-w64-ucrt64-fmt’)
makedepends=(‘mingw-w64-ucrt64-cmake’ ‘mingw-w64-ucrt64-ninja’)
source=(“$pkgname-$pkgver.tar.gz::https://github.com/example/libfastser/archive/refs/tags/v$pkgver.tar.gz”)
sha256sums=(‘e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855’)

ビルド前の準備（必要に応じてパッチをあてるなど）
prepare() {
cd “$srcdir/libfastser-$pkgver”
mkdir -p build
}

実際のビルド処理（CMakeとNinjaを使用し、マルチコアビルドを強制）
build() {
cd “$srcdir/libfastser-$pkgver/build”

# MSYS2が提供する環境変数（${MINGW_PREFIX}など）を完全に活用する
cmake .. \
-G “Ninja” \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=”${MINGW_PREFIX}”

ninja
}

テストスイートの実行（開発の信頼性を担保するため必ず組み込む）
check() {
cd “$srcdir/libfastser-$pkgver/build”
ninja test
}

バイナリのパッケージング（${pkgdir}配下に所定の構造でインストール）
package() {
cd “$srcdir/libfastser-$pkgver/build”
DESTDIR=”$pkgdir” ninja install
}

アーキテクトの解説：ここがポイント

1. 命名規則の厳守: MSYS2のMinGWパッケージ群は `mingw-w64-–` というプレフィックスを強制される（例: `ucrt64` なら `mingw-w64-ucrt64-libfastser`）。これを守ることで、環境ごとの競合を防げる。
2. `${MINGW_PREFIX}` の利用: ハードコードされたパス（`C:/msys64/…`）絶対禁止。環境変数を用いることで、UCRT64でもClang64でも同じスクリプトで柔軟にビルド先を切り替えられる。
3. Ninjaの活用: 大規模なC++コードベースにおいて、MakeよりもNinjaを使う方がビルド速度が数倍跳ね上がる。開発速度に直結するため、`makedepends` に必ず含めよう。

—

3. バイナリのビルドとパッケージ生成

`PKGBUILD` を配置したディレクトリで、MSYS2の専用シェル（UCRT64環境など）を開き、以下のコマンドを叩く。

–clean: ビルド前の古い一時ファイルを削除
–syncdeps: 足りない依存パッケージ(makedepends)を自動で解決・インストール
–noconfirm: プロンプトをスキップして自動化を促進
makepkg-mingw –clean –syncdeps –noconfirm

ビルドが正常に完了すると、同階層に `mingw-w64-ucrt64-libfastser-1.2.0-1-any.pkg.tar.zst` という圧縮アーカイブが生成される。これが君の手で作り上げた独自のPacmanバイナリパッケージだ。

—

4. ローカルリポジトリの作成とチーム共有術

単にパッケージを作っただけでは、`pacman -S` でインストールできない。自作パッケージを管理するための「ローカルリポジトリ」を構築し、それをチームメンバーと共有するフローを確立する。

ステップ1: リポジトリ用ディレクトリの作成

適当な場所（例: `/var/local/custom-repo` や、チーム共有のネットワークドライブ、社内S3など）にリポジトリ用のフォルダを作る。

mkdir -p /var/local/custom-repo
cp ~/packages/libfastser/.pkg.tar.zst /var/local/custom-repo/

ステップ2: データベースの索引作成 (`repo-add`)

Pacmanはフォルダ内のファイルを直接スキャンするのではなく、専用のデータベースファイル（`.db.tar.zst`）を参照する。以下のコマンドでインデックスを生成・更新する。

cd /var/local/custom-repo
repo-add custom-repo.db.tar.gz mingw-w64-ucrt64-libfastser-1.2.0-1-any.pkg.tar.zst

※ 新しいパッケージを追加するたびに、この `repo-add` コマンドを実行してデータベースを更新すればよい。

ステップ3: Pacmanへのリポジトリ登録設定

クライアント側のマシンで、`/etc/pacman.conf` を管理者権限で編集し、公式リポジトリよりも上部（最優先）に自作リポジトリを追加する。

`/etc/pacman.conf` の設定例

[settings]
既存の設定はそのまま…

— ここから追加 —
[custom-repo]
ローカルディレクトリパス、またはファイルサーバーのURLを指定可能
例: ファイル共有サーバーを使う場合 “file:///m:/shared/msys2/custom-repo”
SigLevel = Optional TrustAll
Server = file:///var/local/custom-repo
— ここまで追加 —

既存の公式リポジトリ
[ucrt64]
Include = /etc/pacman.d/mirrorlist.ucrt64

[msys]
Include = /etc/pacman.d/mirrorlist.msys

ステップ4: インストールと動作確認

リポジトリデータベースを同期し、自作パッケージをインストールする。

リポジトリの同期
pacman -Sy

自作パッケージのインストール
pacman -S mingw-w64-ucrt64-libfastser

見事に依存関係が解決され、システムの管理下としてクリーンにインストールされたはずだ。アンインストールしたくなれば `pacman -R mingw-w64-ucrt64-libfastser` を叩くだけで、システムから一切のゴミを残さずに削除できる。

—

5. チーム開発を加速させるためのプロの運用ルール

この仕組みを個人のローカル環境で終わらせるのはもったいない。チーム全体の開発スピードを爆発的に高めるための運用ルールを提示しよう。

1. PKGBUILD専用のリポジトリをGit管理する
ソースコードのプロジェクトとは別に、`msys2-pkgs` のような専用のGitリポジトリを作成し、チーム全員が書いた `PKGBUILD` をコードレビューを通した上で管理する。
2. CI/CDによる自動ビルドの導入 (GitHub Actions等)
GitHub ActionsのWindowsランナー上でMSYS2環境を立ち上げ、`PKGBUILD` から自動で `.pkg.tar.zst` をビルドしてGitHub Releasesにアップロード、あるいは社内Artifactsへプッシュするパイプラインを構築する。これにより、人間が手動でコンパイルする手間がゼロになる。
3. `pacman.conf` のプロビジョニング自動化
新人エンジニアが参画した際、環境構築スクリプト（PowerShell等）に「社内リポジトリの登録」と「初期パッケージのインストール」を記述しておき、コマンド一発で全員が完全に同一のバイナリ環境を手に入れられるようにする。

—

6. まとめ

MSYS2/Pacmanを使いこなし、`PKGBUILD` による自作パッケージングとローカルリポジトリ運用を手に入れることは、WindowsにおけるC/C++開発のストレスを根底から覆す。

「環境依存の謎のエラー」や「手動ビルドによるファイル散逸」といった、開発者のメンタルをすり減らす無駄な労力から解放されよう。インフラストラクチャをコードとパッケージ管理で完全にコントロール下置き、真に価値のあるビジネスロジックの創造にエンジニアリングリソースを集中させてほしい。

スポンサーリンク
タイトルとURLをコピーしました