.. _label2:
-2. OMakeクイックスタートガイド
+OMakeクイックスタートガイド
==================================
.. _label2.1:
-2.1 概要
+概要
----------------------------------
.. omake is designed for building projects that might have source files in several directories. Projects are normally specified using an OMakefile in each of the project directories, and an OMakeroot file in the root directory of the project. The OMakeroot file specifies general build rules, and the OMakefiles specify the build parameters specific to each of the subdirectories. When omake runs, it walks the configuration tree, evaluating rules from all of the OMakefiles. The project is then built from the entire collection of build rules.
single: .SCANNER
.. _label2.1.1:
-2.1.1 自動的な依存関係の解析
+自動的な依存関係の解析
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. Dependency analysis has always been problematic with the make(1) program. omake addresses this by adding the .SCANNER target, which specifies a command to produce dependencies. For example, the following rule
single: .omakedb
.. _label2.1.2:
-2.1.2 ファイル内容から依存関係を解析
+ファイル内容から依存関係を解析
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. Dependency analysis in omake uses MD5 digests to determine whether files have changed. After each run, omake stores the dependency information in a file called .omakedb in the project root directory. When a rule is considered for execution, the command is not executed if the target, dependencies, and command sequence are unchanged since the last run of omake. As an optimization, omake does not recompute the digest for a file that has an unchanged modification time, size, and inode number.
single: .SUFFIXES
.. _label2.2:
-2.2 既にmakeに慣れている人向けの注意事項
+既にmakeに慣れている人向けの注意事項
------------------------------------------
.. For users already familiar with the make(1) command, here is a list of differences to keep in mind when using omake.
single: .DEFAULT
.. _label2.3:
-2.3 小さなCプログラムのビルド
+小さなCプログラムのビルド
--------------------------------
.. To start a new project, the easiest method is to change directories to the project root and use the command omake --install to install default OMakefiles.
single: StaticCLibrary()
.. _label2.4:
-2.4 巨大なプロジェクト
+巨大なプロジェクト
-------------------------
.. As the project grows it is likely that we will want to build libraries of code. Libraries can be built using the StaticCLibrary function. Here is an example of an OMakefile with two libraries.
single: if
.. _label2.5:
-2.5 サブディレクトリ
+サブディレクトリ
--------------------------
.. As the project grows even further, it is a good idea to split it into several directories. Suppose we place the libfoo and libbar into subdirectories.
.. _label2.6:
-2.6 その他の考慮事項
+その他の考慮事項
--------------------------
.. omake also handles recursive subdirectories. For example, suppose the foo directory itself contains several subdirectories. The foo/OMakefile would then contain its own .SUBDIRS target, and each of its subdirectories would contain its own OMakefile.
single: OCaml
.. _label2.7:
-2.7 OCamlプログラムのビルド
+OCamlプログラムのビルド
----------------------------
.. By default, omake is also configured with functions for building OCaml programs. The functions for OCaml program use the OCaml prefix. For example, suppose we reconstruct the previous example in OCaml, and we have a file called hello_code.ml that contains the following code.
single: OMakeroot
.. _label2.8:
-2.8 OMakefileとOMakeroot
+OMakefileとOMakeroot
------------------------------------
.. OMake uses the OMakefile and OMakeroot files for configuring a project. The syntax of these files is the same, but their role is slightly different. For one thing, every project must have exactly one OMakeroot file in the project root directory. This file serves to identify the project root, and it contains code that sets up the project. In contrast, a multi-directory project will often have an OMakefile in each of the project subdirectories, specifying how to build the files in that subdirectory.
single: 仮想的なマウント
.. _label2.9:
-2.9 複数のバージョンのサポート
+複数のバージョンのサポート
-----------------------------------
.. OMake version 0.9.6 introduced preliminary support for multiple, simultaneous versions of a project. Versioning uses the vmount(dir1, dir2) function, which defines a “virtual mount” of directory dir1 over directory dir2. A “virtual mount” is like a transparent mount in Unix, where the files from dir1 appear in the dir2 namespace, but new files are created in dir2. More precisely, the filename dir2/foo refers to: a) the file dir1/foo if it exists, or b) dir2/foo otherwise.
.. _label2.10:
-2.10 注意点
+注意点
--------------------
.. When using the vmount function for versioning, it wise to keep the source files distinct from the compiled versions. For example, suppose the source directory contained a file src/foo.o. When mounted, the foo.o file will be the same in all versions, which is probably not what you want. It is better to keep the src/ directory pristine, containing no compiled code.
OSDN Git Service
