Documentation index

ソースコードからビルドする(Building from source)

ビルドに関連するツールをソースコードからビルドするのは、ユーザーが再ビルドできるようにする方法の1つです。 ソースコードを使うようにしていれば、新しい機能を使うようにできるし、異なるプラットフォームで実行するのも簡単です。 依存対象のリストが長すぎるとそれ以上規模を拡大するのが難しくなるし、あらゆる場面で GCC を再ビルドさせるのはユーザーにとって好ましい方法ではありません。

以降は、ソースコードからコンパイルに関連するツールをビルドする方法の説明です。

外部リソースを使用してビルドする

いろいろなコンポーネントのソースコードをインターネット経由で取得できるようになっています。 tar 玉形式のアーカイブは キャッシュやミラーやチェックサム計算と検証 が簡単なのでお勧めです。 バージョン管理システムからソースコードを取得するときは、正確にバージョンを指定する方法で取得しましょう。 Git ならタグと検証済み署名あるいはコミットハッシュを使うのが一番です。

コンパイル処理は独自のシェルスクリプトや Makefile のターゲットに記述します。

coreboot はちょうどいい具体例です。 ドキュメントには coreboot 本体をビルドする前に make crossgcc を実行せよと記述されています。

全てのリソースをチェックインしておく

全てのツールチェインのソースコードをプロジェクトのバージョン管理システムへチェックインしておくのも1つの方法として感がられます。

これは各種 BSD 系列の OS と同じ方法です。 “Building the world” という操作は、バージョン管理システムから取得したソースコードよりツールチェインをビルドして、それから OS をビルドする操作なのです。

Google の内部プロジェクトも同じ方法です。 Bazel は独自のコンパイルツールに基づくツールで、大規模なビルドにおける速度と再現性を考慮した設計になっています。

完全に統合されたOSや組織化された環境以外で、10や20ものツールチェインをソースコードに統合する考え方を受け入れてもらうのは難しいでしょう。

ツールチェインをビルド結果として配布する

全てのユーザーに全てのツールチェインを再ビルドしてもらうのが難しい場合がほとんどです(時間の都合など)。 OpenWrt プロジェクトは中立的な立場のちょうどいい具体例です。 システムイメージと一緒にダウンロードした “SDK” には、追加パッケージをビルド(再ビルド)するために必要な全てのリソースが含まれているのです。

この場合、SDK 自体を独立したビルドされたソフトウェアとして扱うことになります。 つまり、再現性を保証しなければならいのです。


Documentation index

Follow us on Twitter @ReproBuilds, Mastodon @reproducible_builds@fosstodon.org & Reddit and please consider making a donation. • Content licensed under CC BY-SA 4.0, style licensed under MIT. Templates and styles based on the Tor Styleguide. Logos and trademarks belong to their respective owners. • Patches welcome via our Git repository (instructions) or via our mailing list. • Full contact info