path: root/files/ja/how_mozilla's_build_system_works/index.html

---
title: How Mozilla's build system works
slug: How_Mozilla's_build_system_works
tags:
  - Build documentation
  - Developing Mozilla
  - 移行
---
<h2 id=".E6.A6.82.E8.A6.81" name=".E6.A6.82.E8.A6.81">概要</h2>

<p>本ドキュメントは、Mozilla の GNU make ベースビルドシステムを必要とする Mozilla 開発者をターゲットとしています。 本ドキュメントでは、ビルドシステムの基本概念と用語ならびに、コンポーネントのコンパイルや jar ファイルの作成といった共通的作業をどのように行うかを解説しています。</p>

<p>本書は Mozilla をただビルドしたい人を対象にはしていません。その場合は<a href="/ja/docs/Build_Documentation">Build Documentation</a>を参照してください。</p>

<h2 id=".E6.A6.82.E5.BF.B5" name=".E6.A6.82.E5.BF.B5">概念</h2>

<p>Mozilla のビルドシステムは <a class="external" href="http://www.gnu.org/software/make/">GNU Make</a> をベースにしたシステムです。最も基本的なレベルでは、make は<em>ターゲット</em>を自動生成するツールで、ターゲットごとに<em>dependencies</em> と<em>rules</em> を生成します。</p>

<p>Mozilla プロジェクトでは、make はライブラリと実行モジュールのコンパイル、chrome の jar ファイル作成、関係ファイルのコピーに使用されます。我々は、2 パスのビルドシステムを使用しています:</p>

<ul>
 <li><strong>export</strong> フェーズでは、public ヘッダファイルを dist/include へコピーし、IDL ファイルから C++ ヘッダファイルを生成します。</li>
 <li><strong>libs</strong> フェーズでは、ライブラリをコンパイルし、 jar ファイルを作成し、IDL ファイルから typelib ファイルを作成します。</li>
</ul>

<p>いずれのフェーズでも、ターゲットを make するだけです。これは、それぞれのディレクトリは export ターゲットとともにまず一度横断し、libs ターゲットとともに、再び横断します。 二段階のビルドは、モジュール間の循環的参照のために存在します。最初にすべてのヘッダファイルを export することで、あるモジュール（Ａとする）は、別のモジュール（Ｂ）の public なヘッダファイルをインクルードしながら、モジュール（Ｂ）はモジュール（Ａ）の public なヘッダファイルをインクルードできます。</p>

<p>その他の重要なツールとして、<strong>configure</strong> が挙げられます。これは、ビルドの最初のステップに実行されます。configure スクリプトはシステムやコンパイラの特徴を決定し、オプションを生成します。configure スクリプトから実行される重要な製品が二つあります:</p>

<ul>
 <li>autoconf.mk ファイルは <a class="external" href="http://lxr.mozilla.org/seamonkey/source/config/autoconf.mk.in">autoconf.mk.in</a>から生成されます。このファイルは、グローバルなビルドオプションを制御する<em>make 変数</em> を含みます。</li>
 <li>Makefile ファイルは、ツリーの至る所にある Makefile.in ファイルから生成されます。ビルドを正確に行うため、Makefile.in 中に記述されたソースディレクトリの場所が置換されます。</li>
</ul>

<p>configure スクリプトは bash シェルベースのものです。このスクリプトは <a class="external" href="http://www.seindal.dk/rene/gnu/">M4</a> とともに書かれた <a class="external" href="http://lxr.mozilla.org/seamonkey/source/configure.in">configure.in</a> と呼ばれるファイルから生成され、最終的なスクリプトを生成するために <a class="external" href="http://www.gnu.org/software/autoconf/">Autoconf</a>を使って処理します。</p>

<h2 id="Makefile_.E3.81.AE.E5.9F.BA.E7.A4.8E" name="Makefile_.E3.81.AE.E5.9F.BA.E7.A4.8E">Makefile の基礎</h2>

<p>Makefile は、非常に複雑にもなり得ますが、Mozilla チームは、大半の Makefile をとてもシンプルにすべく、多数のビルトインルールを提供しています。make についての網羅的な解説は本説明の範囲を超えますので、<a class="external" href="http://www.gnu.org/software/make/manual/make.html">こちら（GNU make）</a>を参照してください。</p>

<p>精通しておくとよいであろう概念の一つとして、make の<em>変数</em>が挙げられます。変数は<code>VARIABLE = VALUE</code> という構文で定義され、その値は<code>$(VARIABLE)</code> と記述することで参照されます。すべての変数は文字列です。</p>

<p>Mozilla のソースコードに含まれる Makefile.in ファイルはすべて同じ基本的なフォーマットで記述されています。</p>

<div>{{ page("/ja/docs/Standard_Makefile_Header") }}</div>

<pre class="eval"># ... Makefile の中心となる本体部分がここに入ります ...
</pre>

<pre class="eval">include $(topsrcdir)/config/rules.mk

# ... 追加のルールがここに入ります ...
</pre>

<ul>
 <li><strong>DEPTH</strong> 変数はMakefile.in から Mozilla ディレクトリの最上位への相対パスがセットされます。</li>
 <li><strong>topsrcdir</strong> は configure によって置換されます。これは Mozilla ディレクトリの最上位 を示します。</li>
 <li><strong>srcdir</strong> もまた、configure によって置換されます。これは、現在のディレクトリに対するソースファイルの場所を示します。ソースツリーからのビルドでは、この値は単に "."（カレントディレクトリ）を示すでしょう。</li>
 <li><strong>VPATH</strong> は、make が必須ファイル（例：ソースファイル）を探す対象ディレクトリの一覧です。</li>
</ul>

<p>この他によく使われる変数の一つとして、特定のビルドターゲットを指定しない <strong>DIRS</strong> があります。DIR は、現在のディレクトリを再帰的に組み込むためのサブディレクトリの一覧です。サブディレクトリは親ディレクトリの<strong>後に</strong>配置されます。以下に例を示します。</p>

<pre class="eval">DIRS = \
       public \
       resources \
       src \
       $(NULL)
</pre>

<p>上記の例は、<em>行結合</em>の例でもあります。行の中の最後に現れるバックスラッシュ<span class="comment">（訳注：通常の日本の環境では￥記号に見えることも多いので注意）</span>は、変数定義が次の行にも続いていることを示します。行の継ぎ目の余分な空白は縮められます。終端の $(NULL) は表記に一貫性を持たせる手段です。これにより、行末のバックスラッシュの有無を気にせず行の追加・削除が行えます。</p>

<h2 id="Makefile_examples" name="Makefile_examples">Makefile examples</h2>

<ul>
 <li><a href="/ja/docs/Standard_Makefile_Header">Standard Makefile Header</a></li>
 <li><a href="/ja/docs/Installing_headers_using_EXPORTS">Installing headers using EXPORTS</a></li>
 <li><a href="/ja/docs/Compiling_interfaces_using_XPIDLSRCS">Compiling interfaces using XPIDLSRCS</a></li>
 <li><a href="/ja/docs/Installing_a_JavaScript_component">Installing a JavaScript component</a></li>
 <li><a href="/ja/docs/Building_a_component_DLL">Building a component DLL</a></li>
 <li><a href="/ja/docs/Building_a_static_library">Building a static library</a></li>
 <li><a href="/ja/docs/Building_a_dynamic_library">Building a dynamic library</a></li>
</ul>

<h2 id=".E3.83.A9.E3.82.A4.E3.83.96.E3.83.A9.E3.83.AA.E3.81.AE.E3.83.93.E3.83.AB.E3.83.89" name=".E3.83.A9.E3.82.A4.E3.83.96.E3.83.A9.E3.83.AA.E3.81.AE.E3.83.93.E3.83.AB.E3.83.89">ライブラリのビルド</h2>

<p>Mozilla のビルドにおけるライブラリは、主として３種に分けられます:</p>

<ul>
 <li><strong>Components</strong> は（静的ビルド時を除いて）共有ライブラリで、 dist/bin/components にインストールされます。Components は他のいかなるライブラリからもリンクされません。</li>
 <li><strong>Non-component shared libraries</strong> には、libxpcom、libmozjs といったライブラリが含まれます。これらのライブラリは dist/bin にインストールされ、<em>リンクもされます</em>。この種のライブラリを新規に作成する必要にせまられることはあまりありません。</li>
 <li><strong>Static libraries</strong> はしばしば共有ライブラリのビルドの中間段階として使われます。 共有ライブラリの一部となるいくつかのディレクトリにソースファイルがある場合などがそれに該当します。静的ライブラリは実行ファイルからリンクされることもあります。</li>
</ul>

<h3 id="Non-component_shared_libraries" name="Non-component_shared_libraries">Non-component shared libraries</h3>

<p>non-component shared library は、複数のコンポーネントが共有しなければならない共通コードがあり、それを XPCOM を通じて共有することが、適切でないもしくは不可能な場合に有用です。 一例として、libmsgbaseutil 向けの Makefile の一部を見てみましょう。これは、mailnews コンポーネント全体からリンクされます:</p>

<pre class="eval">DEPTH           = ../../..
topsrcdir       = @top_srcdir@
srcdir          = @srcdir@
VPATH           = @srcdir@

include $(DEPTH)/config/autoconf.mk

<a href="/ja/docs/MODULE">MODULE</a>          = msgbaseutil
<a href="/ja/docs/LIBRARY_NAME">LIBRARY_NAME</a>    = msgbaseutil
<a href="/ja/docs/EXPORT_LIBRARY">EXPORT_LIBRARY</a> = 1
<a href="/ja/docs/SHORT_LIBNAME">SHORT_LIBNAME</a>   = msgbsutl
</pre>

<p>上述した component の例との実際問題としての相違点は、IS_COMPONENT が設定されていない事だけである点に注意してください。この値を設定しない事によって、共有ライブラリが生成され、dist/bin にインストールされるでしょう。</p>

<h3 id="Static_libraries" name="Static_libraries">Static libraries</h3>

<p>上述の通り、静的ライブラリの主要な使用方法としては、大規模ライブラリ（主に component）のビルドの中間段階としての使用が挙げられます。これにより、複数のサブディレクトリにソースファイルを分散させて配置することができます。静的ライブラリは実行可能モジュールにもリンクされることがあります。例として、layout/base/src の Makefile の一部を以下に示します。</p>

<pre class="eval">DEPTH           = ../../..
topsrcdir       = @top_srcdir@
srcdir          = @srcdir@
VPATH           = @srcdir@

include $(DEPTH)/config/autoconf.mk

MODULE          = layout
LIBRARY_NAME    = gkbase_s

# REQUIRES and CPPSRCS omitted here for brevity #

# we don't want the shared lib, but we want to force the creation of a static lib.
<a href="/ja/docs/FORCE_STATIC_LIB">FORCE_STATIC_LIB</a> = 1

include $(topsrcdir)/config/rules.mk
</pre>

<p>ここでは <strong>FORCE_STATIC_LIB</strong> = 1 というキーが設定されています。これにより、（unix の場合)libgkbase_s.a が、Windows の場合はgkbase_s.lib が生成され、dist/lib にコピーされます。では、コンポーネントを作成するために複数の静的ライブラリを合わせてリンクする方法をざっと見てみましょう。</p>

<pre class="eval">DEPTH           = ../..
topsrcdir       = @top_srcdir@
srcdir          = @srcdir@
VPATH           = @srcdir@

include $(DEPTH)/config/autoconf.mk

MODULE          = layout
LIBRARY_NAME    = gklayout
EXPORT_LIBRARY = 1
<a href="/ja/docs/IS_COMPONENT">IS_COMPONENT</a>    = 1
<a href="/ja/docs/MODULE_NAME">MODULE_NAME</a>     = nsLayoutModule

<a href="/ja/docs/CPPSRCS">CPPSRCS</a>         = \
                nsLayoutModule.cpp \
                $(NULL)

<a href="/ja/docs/SHARED_LIBRARY_LIBS">SHARED_LIBRARY_LIBS</a> = \
                $(DIST)/lib/$(LIB_PREFIX)gkhtmlbase_s.$(LIB_SUFFIX) \
                $(DIST)/lib/$(LIB_PREFIX)gkhtmldoc_s.$(LIB_SUFFIX) \
                $(DIST)/lib/$(LIB_PREFIX)gkhtmlforms_s.$(LIB_SUFFIX) \
                $(DIST)/lib/$(LIB_PREFIX)gkhtmlstyle_s.$(LIB_SUFFIX) \
                $(DIST)/lib/$(LIB_PREFIX)gkhtmltable_s.$(LIB_SUFFIX) \
                $(DIST)/lib/$(LIB_PREFIX)gkxulbase_s.$(LIB_SUFFIX) \
                $(DIST)/lib/$(LIB_PREFIX)gkbase_s.$(LIB_SUFFIX) \
                $(DIST)/lib/$(LIB_PREFIX)gkconshared_s.$(LIB_SUFFIX) \
                $(DIST)/lib/$(LIB_PREFIX)gkxultree_s.$(LIB_SUFFIX) \
                $(DIST)/lib/$(LIB_PREFIX)gkxulgrid_s.$(LIB_SUFFIX) \
                $(NULL)

include $(topsrcdir)/config/rules.mk
</pre>

<p><strong>SHARED_LIBRARY_LIBS</strong> は、本共有ライブラリにリンクすべき静的ライブラリを並べて記述します。<strong>LIB_PREFIX</strong> や <strong>LIB_SUFFIX</strong> を使用することで、すべてのプラットフォームで動作させることができることに注意してください。</p>

<h2 id="Jar_.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.82.92.E3.83.93.E3.83.AB.E3.83.89.E3.81.99.E3.82.8B" name="Jar_.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.82.92.E3.83.93.E3.83.AB.E3.83.89.E3.81.99.E3.82.8B">Jar ファイルをビルドする</h2>

<p>Jar ファイルは(XUL、JavaScript、CSSといった) chrome ファイルのパッケージングに使用します。Jar パッケージングについてのより詳細な情報は、{{ mediawiki.external('jar-packaging.html このドキュメント') }}で得られます。ここでは、Jar パッケージを行うために Makefile をどのように設定するかのみ述べます。以下に例を示します。</p>

<pre class="eval">DEPTH           = ../../../..
topsrcdir       = @top_srcdir@
srcdir          = @srcdir@
VPATH           = @srcdir@

include $(DEPTH)/config/autoconf.mk

include $(topsrcdir)/config/rules.mk</pre>

<p>そうです。ここでは定義が必要な外部変数は使用されていません。Makefile.in と同じディレクトリに <strong>jar.mn</strong> ファイルがある場合、自動的に処理されるのです。jar.mn と chrome ファイルを含む <strong>resources</strong> ディレクトリを作成するのが通例ですが、ライブラリを作成するディレクトリに jar.mn を設置したいのであれば、これも動作します（処理されます）。</p>

<div class="originaldocinfo">
<h2 id="著作情報">著作情報</h2>

<ul>
 <li>著作者: Brian Ryner</li>
 <li>著作権情報: Portions of this content are © 1998–2006 by individual mozilla.org contributors; content available under a Creative Commons license</li>
</ul>
</div>