OSDN Git Service

LaTex用に更新.
[omake-japanese/omake_trans.git] / build-examples.rst
index 26a1e77..b65b363 100644 (file)
@@ -6,7 +6,7 @@
    single: OSTYPE
 .. _label3:
 
-3. OMakeビルドサンプル
+OMakeビルドサンプル
 ==================================
 .. Let's explain the OMake build model a bit more. One issue that dominates this discussion is that OMake is based on global project analysis. That means you define a configuration for the entire project, and you run one instance of omake.
 
@@ -105,7 +105,7 @@ GNU/BSDのmakeユーザは以下の点に留意してください。
    single: OMakefile
 .. _label3.1:
 
-3.1  OMakeroot vs. OMakefile
+OMakeroot vs. OMakefile
 ----------------------------------
 .. Before we begin with examples, let's ask the first question, “What is the difference between the project root OMakeroot and OMakefile?” A short answer is, there is no difference, but you must have an OMakeroot file (or Root.om file).
 
@@ -131,7 +131,7 @@ OMakeを始めるために、あなたがこのような決まり文句を入力
    single: DefineCommandVars()
 .. _label3.2:
 
-3.2  Cプロジェクトのサンプル
+Cプロジェクトのサンプル
 ------------------------------
 .. To begin, let's start with a simple example. Let's say that we have a full directory tree, containing the following files.
 
@@ -227,7 +227,7 @@ OMakeを始めるために、まずは簡単なサンプルから始めてみま
    single: OCamlProgram()
 .. _label3.3:
 
-3.3  OCamlプロジェクトのサンプル
+OCamlプロジェクトのサンプル
 ------------------------------------
 .. Let's repeat the example, assuming we are using OCaml instead of C. This time, the directory tree looks like this.
 
@@ -319,7 +319,7 @@ OMakeを始めるために、まずは簡単なサンプルから始めてみま
 
 .. _label3.4:
 
-3.4  新しい言語を扱う
+新しい言語を扱う
 ------------------------
 .. The previous two examples seem to be easy enough, but they rely on the OMake standard library (the files build/C and build/OCaml) to do all the work. What happens if we want to write a build configuration for a language that is not already supported in the OMake standard library?
 
@@ -363,7 +363,7 @@ OMakeを始めるために、まずは簡単なサンプルから始めてみま
    single: mapprefix()
 .. _label3.4.1:
 
-3.4.1  通常の編集ルールの定義
+通常の編集ルールの定義
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 .. Let's start with part 2, defining a generic compilation rule. We'll define the build rule as an implicit rule. To handle the include path, we'll define a variable CAT_INCLUDES that specifies the include path. This will be an array of directories. To define the options, we'll use a lazy variable (Section 7.5). In case there are any other standard flags, we'll define a CAT_FLAGS variable.
 
@@ -396,7 +396,7 @@ OMakeを始めるために、まずは簡単なサンプルから始めてみま
    single: addsuffix()
 .. _label3.4.2:
 
-3.4.2  リンクするためのルールを定義
+リンクするためのルールを定義
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 .. For linking, we'll define another rule describing how to perform linking. Instead of defining an implicit rule, we'll define a function that describes the linking step. The function will take two arguments; the first is the name of the executable (without suffix), and the second is the files to link (also without suffixes). Here is the code fragment.
 
@@ -439,7 +439,7 @@ OMakeを始めるために、まずは簡単なサンプルから始めてみま
    single: awk()
 .. _label3.4.3:
 
-3.4.3  依存関係の解析
+依存関係の解析
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 .. That's it, almost. The part we left out was automated dependency scanning. This is one of the nicer features of OMake, and one that makes build specifications easier to write and more robust. Strictly speaking, it isn't required, but you definitely want to do it.
 
@@ -505,7 +505,7 @@ OMakeを始めるために、まずは簡単なサンプルから始めてみま
 
 .. _label3.4.4:
 
-3.4.4  まとめ
+まとめ
 ^^^^^^^^^^^^^^^^^^^
 .. To complete the example, let's pull it all together into a single project, much like our previous example.
 
@@ -633,7 +633,7 @@ OMakeを始めるために、まずは簡単なサンプルから始めてみま
    single: OMAKEPATH
 .. _label3.4.5:
 
-3.4.5  終わりに
+終わりに
 ^^^^^^^^^^^^^^^^^^
 .. At this point we are done, but there are a few things we can consider.
 
@@ -652,7 +652,7 @@ OMakeを始めるために、まずは簡単なサンプルから始めてみま
    single: absname()
 .. _label3.5:
 
-3.5  階層構造、.SUBDIRSの内容を並列化させる
+階層構造、.SUBDIRSの内容を並列化させる
 -------------------------------------------
 .. Some projects have many subdirectories that all have the same configuration. For instance, suppose you have a project with many subdirectories, each containing a set of images that are to be composed into a web page. Apart from the specific images, the configuration of each file is the same.
 
@@ -689,7 +689,7 @@ OMakeを始めるために、まずは簡単なサンプルから始めてみま
    single: ls()
 .. _label3.5.1:
 
-3.5.1  globパターンを扱う
+globパターンを扱う
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 .. Of course, this specification is quite rigid. In practice, it is likely that each subdirectory will have a different set of images, and all should be included in the web page. One of the easier solutions is to use one of the directory-listing functions, like glob or ls. The glob function takes a shell pattern, and returns an array of file with matching filenames in the current directory.
 
@@ -735,7 +735,7 @@ OMakeを始めるために、まずは簡単なサンプルから始めてみま
    single: dirof()
 .. _label3.5.3:
 
-3.5.3  サブディレクトリのリストを計算
+サブディレクトリのリストを計算
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 .. The other hardcoded specification is the list of subdirectories page1, ..., page4. Rather than editing the project OMakefile each time a directory is added, we could compute it (again with glob).
 
@@ -802,7 +802,7 @@ OMakeを始めるために、まずは簡単なサンプルから始めてみま
    single: CREATE_SUBDIRS
 .. _label3.5.4:
 
-3.5.4  一時的なディレクトリ
+一時的なディレクトリ
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 .. Sometimes, your project may include temporary directories–directories where you place intermediate results. these directories are deleted whenever the project is cleanup up. This means, in particular, that you can't place an OMakefile in a temporary directory, because it will be removed when the directory is removed.