single: $<
.. _label8:
-8. ビルドルール
+ビルドルール
==================================
.. Rules are used by OMake to specify how to build files. At its simplest, a rule has the following form.
single: ワイルドカード
.. _label8.1:
-8.1 暗黙のルール
+暗黙のルール
----------------------------------
.. Rules may also be implicit. That is, the files may be specified by wildcard patterns. The wildcard character is %. For example, the following rule specifies a default rule for building .o files.
.. _label8.2:
-8.2 束縛された暗黙のルール
+束縛された暗黙のルール
----------------------------------
.. Implicit rules may specify the set of files they apply to. The following syntax is used.
single: section
.. _label8.3:
-8.3 section
+section
----------------------------------
.. Frequently, the commands in a rule body are expressions to be evaluated by the shell. omake also allows expressions to be evaluated by omake itself.
single: section rule
.. _label8.4:
-8.4 section rule
+section rule
----------------------------------
.. Rules can also be computed using the section rule form, where a rule body is expected instead of an expression. In the following rule, the file a.c is copied onto the hello.c file if it exists, otherwise hello.c is created from the file default.c.
.. _label8.5:
-8.5 特別な依存関係
+特別な依存関係
----------------------------------
.. index::
single: :exists:
.. _label8.5.1:
-8.5.1 :exists:
+\:exists:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. In some cases, the contents of a dependency do not matter, only whether the file exists or not. In this case, the :exists: qualifier can be used for the dependency.
single: :effects:
.. _label8.5.2:
-8.5.2 :effects:
+\:effects:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. Some commands produce files by side-effect. For example, the latex(1) command produces a .aux file as a side-effect of producing a .dvi file. In this case, the :effects: qualifier can be used to list the side-effect explicitly. omake is careful to avoid simultaneously running programs that have overlapping side-effects.
single: :value:
.. _label8.5.3:
-8.5.3 :value:
+\:value:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. The :value: dependency is used to specify that the rule execution depends on the value of an expression. For example, the following rule
single: digest-in-path-optional()
.. _label8.6:
-8.6 .SCANNER ルール
+.SCANNER ルール
----------------------------------
.. Scanner rules define a way to specify automatic dependency scanning. A .SCANNER rule has the following form.
single: :scanner:
.. _label8.6.1:
-8.6.1 スキャナの命名と :scanner: 依存関係
+スキャナの命名と :scanner: 依存関係
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. Sometimes it may be useful to specify explicitly which scanner should be used in a rule. For example, we might compile .c files with different options, or (heaven help us) we may be using both gcc and the Microsoft Visual C++ compiler cl. In general, the target of a .SCANNER is not tied to a particular target, and we may name it as we like.
single: SCANNER_MODE
.. _label8.6.2:
-8.6.2 ノート
+ノート
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. In most cases, you won't need to define scanners of your own. The standard installation includes default scanners (both explicitly and implicitly named ones) for C, OCaml, and LATEX files.
single: .DEFAULT
.. _label8.7:
-8.7 .DEFAULT
+.DEFAULT
----------------------------------
.. The .DEFAULT target specifies a target to be built by default if omake is run without explicit targets. The following rule instructs omake to build the program hello by default
single: .SUBDIRS
.. _label8.8:
-8.8 .SUBDIRS
+.SUBDIRS
----------------------------------
.. The .SUBDIRS target is used to specify a set of subdirectories that are part of the project. Each subdirectory should have its own OMakefile, which is evaluated in the context of the current environment.
single: .INCLUDE
.. _label8.9:
-8.9 .INCLUDE
+.INCLUDE
----------------------------------
.. The .INCLUDE target is like the include directive, but it specifies a rule to build the file if it does not exist.
single: .PHONY
.. _label8.10:
-8.10 .PHONY
+.PHONY
----------------------------------
.. A “phony” target is a target that is not a real file, but exists to collect a set of dependencies. Phony targets are specified with the .PHONY rule. In the following example, the install target does not correspond to a file, but it corresponds to some commands that should be run whenever the install target is built (for example, by running omake install).
.. _label8.11:
-8.11 スコープ規則
+スコープ規則
----------------------------------
.. As we have mentioned before, omake is a scoped language. This provides great flexibility—different parts of the project can define different configurations without interfering with one another (for example, one part of the project might be compiled with CFLAGS=-O3 and another with CFLAGS=-g).
single: 暗黙のルール
.. _label8.11.1:
-8.11.1 暗黙のルールのスコーピング
+暗黙のルールのスコーピング
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. Implicit rules (rules containing wildcard patterns) are not global, they follow the normal scoping convention. This allows different parts of a project to have different sets of implicit rules. If we like, we can modify the example above to provide a new implicit rule for building hello_lib.o.
single: :scanner:
.. _label8.11.2:
-8.11.2 .SCANNER ルールのスコーピング
+.SCANNER ルールのスコーピング
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. Scanner rules are scoped the same way as normal rules. If the .SCANNER rule is explicit (containing no wildcard patterns), then the scope of the scan target is the same as the the rule. If the .SCANNER rule is implicit, then the environment is taken from the :scanner: dependency.
single: .SUBDIRS
.. _label8.11.3:
-8.11.3 .PHONY ターゲットのスコーピング
+.PHONY ターゲットのスコーピング
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. Phony targets (targets that do not correspond to files) are defined with a .PHONY: rule. Phony targets are scoped as usual. The following illustrates a common mistake, where the .PHONY target is declared after it is used.
.. _label8.12:
-8.12 サブディレクトリからOMakeを実行
+サブディレクトリからOMakeを実行
----------------------------------------------
.. Running omake foo asks OMake to build the file foo in context of the whole project, even when running from a subdirectory of the project. Therefore, if bar/baz is a regular target (not a .PHONY one), then running omake bar/baz and running (cd bar; omake baz) are usually equivalent.
single: .PHONY
.. _label8.12.1:
-8.12.1 サブディレクトリのPhonyターゲット
+サブディレクトリのPhonyターゲット
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. Suppose you have a .PHONY: clean declared in your root OMakefile and both the root OMakefile and the OMakefile in some of the subdirectories contain clean: rules. In this case
.. _label8.12.2:
-8.12.2 .PHONYターゲットの階層構造
+.PHONYターゲットの階層構造
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. When the the root OMakefile contains a .PHONY: clean directive, it creates:
single: OMakeFlags()
.. _label8.13:
-8.13 ルール中でのパス名
+ルール中でのパス名
----------------------------------
.. In rules, the targets and dependencies are first translated to file values (as in the file function). They are then translated to strings for the command line. This can cause some unexpected behavior. In the following example, the absname function is the absolute pathname for the file a, but the rule still prints the relative pathname.
OSDN Git Service
