Jump to:    OMake Home • Guide Home • Guide (single-page) • Contents (short) • Contents (long)
Index:    All • Variables • Functions • Objects • Targets • Options

Chapter 12  Build functions

12.1  Builtin .PHONY targets

The complete set of builtin .PHONY targets include the following.
.PHONY
Declares new phony targets (Section 7.12).
.DEFAULT
Declare the default build targets (Section 7.9).
.SUBDIRS
Include a directory as part of the project (Section 7.10).
.SCANNER
Define a dependency scanner (Section 7.10).
.INCLUDE
Include a file (Section 7.11).
.ORDER
Define a file-dependency ordering rule (Section 9.3.5).
.BUILD_BEGIN
Commands to be executed at the beginning of a build.
.BUILD_SUCCESS
Commands to be executed if the build is successful.
.BUILD_FAILURE
Commands to be executed if the build fails.
The .BUILD targets can be used to specify commands to be executed at the beginning and end of the build. The .BUILD_BEGIN target is built at the beginning of a project build, and one of .BUILD_FAILURE or .BUILD_SUCCESS is executed when the build terminates.

For example, the following set of rules simply print additional messages about the status of the build.
   .BUILD_BEGIN:
       echo Build starting

   .BUILD_SUCCESS:
       echo The build was successful

   .BUILD_FAILURE:
       println($"The build failed: $(length $(find-build-targets Failed)) targets could not be built")
Another common use is to define notifications to be performed when the build completes. For example, the following rule will create a new X terminal displaying the summary of the build (see BUILD_SUMMARY in Section 8.1.12).
    .BUILD_FAILURE:
        xterm -e vi $(BUILD_SUMMARY)
If you do not wish to add these rules directly to your project (which is probably a good idea if you work with others), you can define them in your .omakerc (see Section A.8).

The find-build-targets function (Section 12.8.0.10 is useful for obtaining a firther summary of the build. Note that when output diversions are in effect (with the --output-* options — see Chapter A), any output produced by the commands is copied to a file. The name of the file is specified by the output-file field of the Target object (Section 11.1.11). You may find this useful in defining custom build summaries.

12.2  Options and versioning

12.2.0.1  OMakeFlags

   OMakeFlags(options)
      options : String
The OMakeFlags function is used to set omake options from within OMakefiles. The options have exactly the same format as options on the command line.

For example, the following code displays the progress bar unless the VERBOSE environment variable is defined.
    if $(not $(defined-env VERBOSE))
        OMakeFlags(-S --progress)
        export

12.2.0.2  OMakeVersion

   OMakeVersion(version1)
   OMakeVersion(version1, version2)
      version1, version2 : String
The OMakeVersion function is used for version checking in OMakefiles. It takes one or two arguments.

In the one argument form, if the omake version number is less than <version1>, then an exception is raised. In the two argument form, the version must lie between version1 and version2.

12.2.0.3  cmp-versions

   $(cmp-versions version1, version2)
      version1, version2 : String
The cmp-versions\ functions can be used to compare arbitrary version strings. It returns 0 when the two version strings are equal, a negative number when the first string represents an earlier version, and a positive number otherwise.

12.2.0.4  DefineCommandVars

   DefineCommandVars()
The DefineCommandVars function redefines the variables passed on the commandline. Variables definitions are passed on the command line in the form name=value. This function is primarily for internal use by omake to define these variables for the first time.

12.3  The OMakeroot file

The standard OMakeroot file defines the functions are rules for building standard projects.

12.3.1  Variables

12.3.1.1  ROOT

The root directory of the current project.

12.3.1.2  CWD

The current working directory (the directory is set for each OMakefile in the project).

12.3.1.3  EMPTY

The empty string.

12.3.1.4  STDROOT

The name of the standard installed OMakeroot file.

12.3.1.5  ABORT_ON_COMMAND_ERROR

If set to true, the construction of a target should be aborted whenever one of the commands to build it fail. This defaults to true, and should normally be left that way.

12.3.1.6  SCANNER_MODE

This variable should be defined as one of four values (defaults to enabled).
enabled
Allow the use of default .SCANNER rules. Whenever a rule does not specify a :scanner: dependency explicitly, try to find a .SCANNER with the same target name.
disabled
Never use default .SCANNER rules.
warning
Allow the use of default .SCANNER rules, but print a warning whenever one is selected.
error
Do not allow the use of default .SCANNER rules. If a rule does not specify a :scanner: dependency, and there is a default .SCANNER rule, the build will terminate abnormally.

12.3.2  System variables

12.3.2.1  INSTALL

The command to install a program (install on Unix, cp on Win32).

12.3.2.2  PATHSEP

The normal path separator (: on Unix, ; on Win32).

12.3.2.3  DIRSEP

The normal directory separator (/ on Unix, \ on Win32).

12.3.2.4  EXT_LIB

File suffix for a static library (default is .a on Unix, and .lib on Win32).

12.3.2.5  EXT_OBJ

File suffix for an object file (default is .o on Unix, and .obj on Win32).

12.3.2.6  EXT_ASM

File suffix for an assembly file (default is .s on Unix, and .asm on Win32).

12.3.2.7  EXE

File suffix for executables (default is empty for Unix, and .exe on Win32 and Cygwin).

12.4  Building C programs

omake provides extensive support for building C programs.

12.4.1  C configuration variables

The following variables can be redefined in your project.

12.4.1.1  CC

The name of the C compiler (on Unix it defaults to gcc when gcc is present and to cc otherwise; on Win32 defaults to cl /nologo).

12.4.1.2  CXX

The name of the C++ compiler (on Unix it defaults to gcc when gcc is present and to c++ otherwise; on Win32 defaults to cl /nologo).

12.4.1.3  CPP

The name of the C preprocessor (defaults to cpp on Unix, and cl /E on Win32).

12.4.1.4  CFLAGS

Compilation flags to pass to the C compiler (default empty on Unix, and /DWIN32 on Win32).

12.4.1.5  CXXFLAGS

Compilation flags to pass to the C++ compiler (default empty on Unix, and /DWIN32 on Win32).

12.4.1.6  INCLUDES

Additional directories that specify the search path to the C and C++ compilers (default is .). The directories are passed to the C and C++ compilers with the -I option. The include path with -I prefixes is defined in the PREFIXED_INCLUDES variable.

12.4.1.7  LIBS

Additional libraries needed when building a program (default is empty).

12.4.1.8  AS

The name of the assembler (defaults to as on Unix, and ml on Win32).

12.4.1.9  ASFLAGS

Flags to pass to the assembler (default is empty on Unix, and /c /coff on Win32).

12.4.1.10  AR

The name of the program to create static libraries (defaults to ar cq on Unix, and lib on Win32).

12.4.1.11  AROUT

The option string that specifies the output file for AR.

12.4.1.12  LD

The name of the linker (defaults to ld on Unix, and cl on Win32).

12.4.1.13  LDFLAGS

Options to pass to the linker (default is empty).

12.4.1.14  YACC

The name of the yacc parser generator (default is yacc on Unix, empty on Win32).

12.4.1.15  LEX

The name of the lex lexer generator (default is lex on Unix, empty on Win32).

12.4.2  Generated C files

Because the C scanners do not normally know anything about generated source files (such as generated header files), these files may need to be created before running the scanner.

12.4.2.1  CGeneratedFiles, LocalCGeneratedFiles

CGeneratedFiles(files)
LocalCGeneratedFiles(files)
The CGeneratedFiles and LocalCGeneratedFiles functions specify files that need to be generated before any C files are scanned for dependencies. For example, if config.h and inputs.h are both generated files, specify:
CGeneratedFiles(config.h inputs.h)
The CGeneratedFiles function is global — its arguments will be generated before any C files anywhere in the project are scanned for dependencies. The LocalCGeneratedFiles function follows the normal scoping rules of OMake.

12.4.3  Building C programs and Libraries

12.4.3.1  StaticCLibrary

The StaticCLibrary builds a static library.

StaticCLibrary(<target>, <files>)

The <target> does not include the library suffix, and The <files> list does not include the object suffix. These are obtained from the EXT_LIB and EXT_OBJ variables.

This function returns the library filename.

The following command builds the library libfoo.a from the files a.o b.o c.o on Unix, or the library libfoo.lib from the files a.obj b.obj c.obj on Win32.
StaticCLibrary(libfoo, a b c)
.DEFAULT: $(StaticCLibrary libbar, a b c d)

12.4.3.2  StaticCLibraryCopy

The StaticCLibraryCopy function copies the static library to an install location.

StaticCLibraryCopy(<tag>, <dir>, <lib>)

The <tag> is the name of a target (typically a .PHONY target); the <dir> is the installation directory, and <lib> is the library to be copied (without the library suffix).

This function returns the filename of the library in the target directory.

For example, the following code copies the library libfoo.a to the /usr/lib directory.
.PHONY: install

StaticCLibraryCopy(install, /usr/lib, libfoo)

12.4.3.3  StaticCLibraryInstall

The StaticCLibraryInstall function builds a library, and sets the install location in one step. It returns the filename of the library in the target directory.

StaticCLibraryInstall(<tag>, <dir>, <libname>, <files>)
StaticCLibraryInstall(install, /usr/lib, libfoo, a b c)

12.4.3.4  StaticCObject, StaticCObjectCopy, StaticCObjectInstall

These functions mirror the StaticCLibrary, StaticCLibraryCopy, and StaticCLibraryInstall functions, but they build an object file (a .o file on Unix, and a .obj file on Win32).

12.4.3.5  CProgram

The CProgram function builds a C program from a set of object files and libraries.

CProgram(<name>, <files>)

The <name> argument specifies the name of the program to be built; the <files> argument specifies the files to be linked. The function returns the filename of the executable.

Additional options can be passed through the following variables.
CFLAGS
Flags used by the C compiler during the link step.
LDFLAGS
Flags to pass to the loader.
LIBS
Additional libraries to be linked.
For example, the following code specifies that the program foo is to be produced by linking the files bar.o and baz.o and libraries libfoo.a.
section
   LIBS = libfoo
   LDFLAGS += -lbar
   CProgram(foo, bar baz)

12.4.3.6  CProgramCopy

The CProgramCopy function copies a file to an install location.

CProgramCopy(<tag>, <dir>, <program>)
CProgramCopy(install, /usr/bin, foo)

12.4.3.7  CProgramInstall

The CProgramInstall function specifies a program to build, and a location to install, simultaneously.

CProgramInstall(<tag>, <dir>, <name>, <files>)
section
   LIBS = libfoo
   LDFLAGS += -lbar
   CProgramInstall(install, /usr/bin, foo, bar baz)

12.4.3.8  CXXProgram, CXXProgramInstall

The CXXProgram and CXXProgramInstall functions are equivalent to their C counterparts, except that would use $(CXX) and $(CXXFLAGS) for linking instead of $(CC) and $(CFLAGS).

12.5  Building OCaml programs

12.5.1  Autoconfiguration variables for OCaml programs

These variables will get defined based on the “autoconf-style” tests executed when you run OMake for the first time. You can use them to configure your project accordingly, and you should not redefine them.

12.5.1.1  OCAMLOPT_EXISTS

True when ocamlopt (or ocamlopt.opt) is available on your machine.

12.5.1.2  OCAMLFIND_EXISTS

True when the ocamlfind is available on your machines.

12.5.1.3  OCAMLDEP_MODULES_AVAILABLE

True when a version of ocamldep that understands the -modules option is available on your machine.

12.5.1.4  MENHIR_AVAILABLE

True when the Menhir parser-generator is available on your machine.

12.5.2  Configuration variables for OCaml programs

The following variables can be redefined in your project.

12.5.2.1  USE_OCAMLFIND

Whether to use the ocamlfind utility (default false\)

12.5.2.2  OCAMLC

The OCaml bytecode compiler (default ocamlc.opt if it exists and USE_OCAMLFIND is not set, otherwise ocamlc).

12.5.2.3  OCAMLOPT

The OCaml native-code compiler (default ocamlopt.opt if it exists and USE_OCAMLFIND is not set, otherwise ocamlopt).

12.5.2.4  CAMLP4

The camlp4 preprocessor (default camlp4).

12.5.2.5  OCAMLLEX

The OCaml lexer generator (default ocamllex).

12.5.2.6  OCAMLLEXFLAGS

The flags to pass to ocamllex (default -q).

12.5.2.7  OCAMLYACC

The OCaml parser generator (default ocamlyacc).

12.5.2.8  OCAMLYACCFLAGS

Additional options to pass to $(OCAMLYACC).

12.5.2.9  OCAMLDEP

The OCaml dependency analyzer (default ocamldep).

12.5.2.10  OCAMLDEP_MODULES

The OCaml dependency analyzer that understands the -module option (default ocamldep, if ocamldep -modules works, or ocamlrun ocamldep-omake, if ocamlrun ocamldep-omake -modules works, and empty when neither works).

12.5.2.11  OCAMLDEP_MODULES_ENABLED

Instead of using OCAMLDEP in a traditional make-style fashion, run $(OCAMLDEP_MODULES) -modules and then postprocess the output internally to discover all the relevant generated .ml and .mli files. See Section 12.6 for more information on interactions between OMake, OCAMLDEP and generated files. This feature is currently considered highly experimental and is disabled by default.

12.5.2.12  OCAMLMKTOP

The OCaml toploop compiler (default ocamlmktop).

12.5.2.13  OCAMLLINK

The OCaml bytecode linker (default $(OCAMLC)).

12.5.2.14  OCAMLOPTLINK

The OCaml native-code linker (default $(OCAMLOPT)).

12.5.2.15  OCAMLINCLUDES

Search path to pass to the OCaml compilers (default .). The search path with the -I prefix is defined by the PREFIXED_OCAMLINCLUDES variable.

12.5.2.16  OCAMLFIND

The ocamlfind utility (default ocamlfind if USE_OCAMLFIND is set, otherwise empty).

12.5.2.17  OCAMLFINDFLAGS

The flags to pass to ocamlfind (default empty, USE_OCAMLFIND must be set).

12.5.2.18  OCAMLPACKS

Package names to pass to ocamlfind (USE_OCAMLFIND must be set).

12.5.2.19  BYTE_ENABLED

Flag indicating whether to use the bytecode compiler (default true, when no ocamlopt found, false otherwise).

12.5.2.20  NATIVE_ENABLED

Flag indicating whether to use the native-code compiler (default true, when ocamlopt is found, false otherwise). Both BYTE_ENABLED and NATIVE_ENABLED can be set to true; at least one should be set to true.

12.5.2.21  MENHIR_ENABLED

Define this as true if you wish to use menhir instead of ocamlyacc (default false).

12.5.3  OCaml command flags

The following variables specify additional options to be passed to the OCaml tools.

12.5.3.1  OCAMLDEPFLAGS

Flags to pass to OCAMLDEP (but not to OCAMLDEP_MODULES).

12.5.3.2  OCAMLPPFLAGS

Flags to pass to CAMLP4.

12.5.3.3  OCAMLCFLAGS

Flags to pass to the byte-code compiler (default -g).

12.5.3.4  OCAMLOPTFLAGS

Flags to pass to the native-code compiler (default empty).

12.5.3.5  OCAMLFLAGS

Flags to pass to either compiler (default -warn-error A).

12.5.3.6  OCAML_BYTE_LINK_FLAGS

Flags to pass to the byte-code linker (default empty).

12.5.3.7  OCAML_NATIVE_LINK_FLAGS

Flags to pass to the native-code linker (default empty).

12.5.3.8  OCAML_LINK_FLAGS

Flags to pass to either linker.

12.5.3.9  MENHIR_FLAGS

Additional flags to pass to menhir.

12.5.4  Library variables

The following variables are used during linking.

12.5.4.1  OCAML_LIBS

Libraries to pass to the linker. These libraries become dependencies of the link step.

12.5.4.2  OCAML_OTHER_LIBS

Additional libraries to pass to the linker. These libraries are not included as dependencies to the link step. Typical use is for the OCaml standard libraries like unix or str.

12.5.4.3  OCAML_CLIBS

C libraries to pass to the linker.

12.5.4.4  OCAML_LIB_FLAGS

Extra flags for the library.

12.6  Generated OCaml Files

As of OCaml version 3.09.2, the standard ocamldep scanner is “broken”. The main issue is that it finds only those dependencies that already exist. If foo.ml contains a dependency on Bar,
foo.ml:
   open Bar
then the default ocamldep will only find the dependency if a file bar.ml or bar.ml exists in the include path. It will not find (or print) the dependency if, for example, only bar.mly exists at the time ocamldep is run, even though bar.ml and bar.mli can be generated from bar.mly.

OMake currently provides two methods for addressing this problem — one that requires manually specifying the generated files, and an experimental method for discovering such “hidden” dependencies automatically. The variable OCAMLDEP_MODULES_ENABLED 12.5.2.11 controls which method is going to be used. When this variable is false, the manual specifications are expected and when it is true, the automated discovery will be attempted.

12.6.0.5  OCamlGeneratedFiles, LocalOCamlGeneratedFiles

OCamlGeneratedFiles(files)
LocalOCamlGeneratedFiles(files)
When the OCAMLDEP_MODULES_ENABLED 12.5.2.11 variable is set to false, the OCamlGeneratedFiles and LocalOCamlGeneratedFiles functions specify files that need to be generated before any OCaml files are scanned for dependencies. For example, if parser.ml and lexer.ml are both generated files, specify:
OCamlGeneratedFiles(parser.ml lexer.ml)
The OCamlGeneratedFiles function is global — its arguments will be generated before any OCaml files anywhere in the project are scanned for dependencies. The LocalOCamlGeneratedFiles function follows the normal scoping rules of OMake.

These functions have no effect when OCAMLDEP_MODULES_ENABLED 12.5.2.11 is true.

12.6.0.6  Automatic discovery of generated files during dependency analysis.

Having to specify the generated files manualy when OMake could discover them automatically is obviously suboptimal. To address this, we try to use a custom ocamldep that only finds the free module names in a file.

This functionality is experimental and is disabled by default for now. Set OCAMLDEP_MODULES_ENABLED 12.5.2.11 to true (or to $(OCAMLDEP_MODULES_AVAILABLE) in your project to enable it.

Note that the experimental ocamldep functionality this relies upon is not yet included in the standard OCaml — see http://caml.inria.fr/mantis/view.php?id=4047. Temporarily, we distribute a bytecode version ocamldep-omake of the appropriately modified ocamldep. The appropriate ocamldep will be discovered automatically — see Sections 12.5.1.3 and 12.5.2.10.

12.6.1  Using the Menhir parser generator

Menhir is a parser generator that is mostly compatible with ocamlyacc, but with many improvements. A few of these are listed here (excerpted from the Menhir home page http://cristal.inria.fr/~fpottier/menhir/). What do you need to do to use Menhir instead of ocamlyacc?
  1. Place the following definition before the relevant section of your project (or at the top of your project OMakefile if you want to use Menhir everywhere).
       MENHIR_ENABLED = true
    


  2. Optionally, add any desired Menhir options to the MENHIR_FLAGS variable.
       MENHIR_FLAGS += --infer
    
With this setup, any file with a .mly suffix will be compiled with Menhir.

If your grammar is split across several files, you need to specify it explicitly, using the MenhirMulti function.
    MenhirMulti(target, sources)
        target : filename, without suffix
        sources : the files that define the grammar, without suffixes
For example, if you want to generate the parser files parse.ml and parse.mli, from the grammar specified in files a.mly and b.mly, you would use the following.
    MenhirMulti(parse, a b)

12.6.1.1  OCamlLibrary

The OCamlLibrary function builds an OCaml library.

OCamlLibrary(<libname>, <files>)

The <libname> and <files> are listed without suffixes.

12.6.1.2  ABORT_ON_DEPENDENCY_ERRORS

The linker requires that the files to be listed in dependency order. If this variable is true, the order of the files is determined by the command line, but omake will abort with an error message if the order is illegal. Otherwise, the files are sorted automatically.

This function returns the list of all the targets that it defines the rules for (including the $(name)$(EXT_LIB) file when NATIVE_ENABLED is set).

The following code builds the libfoo.cmxa library from the files foo.cmx and bar.cmx (if NATIVE_ENABLED is set), and libfoo.cma from foo.cmo and bar.cmo (if BYTE_ENABLED is set).
OCamlLibrary(libfoo, foo bar)

12.6.1.3  OCamlPackage

The OCamlPackage function builds an OCaml package.

OCamlPackage(<name>, <files>)

The <name> and <files> are listed without suffixes. The <files> must have been compiled with the -for-pack <ident> flag to the OCaml compiler.

This function returns the list of all the targets that it defines the rules for (including the $(name)$(EXT_LIB) file when NATIVE_ENABLED is set).

The following code builds the libfoo.cmx package from the files package.cmx and bar.cmx (if NATIVE_ENABLED is set), and package.cmo from foo.cmo and bar.cmo (if BYTE_ENABLED is set).
OCamlPackage(package, foo bar)

12.6.1.4  OCamlLibraryCopy

The OCamlLibraryCopy function copies a library to an install location.

OCamlLibraryCopy(<tag>, <libdir>, <libname>, <interface-files>)

The <interface-files> specify additional interface files to be copied if the INSTALL_INTERFACES variable is true.

12.6.1.5  OCamlLibraryInstall

The OCamlLibraryInstall function builds a library and copies it to an install location in one step.

OCamlLibraryInstall(<tag>, <libdir>, <libname>, <files>)

12.6.1.6  OCamlProgram

The OCamlProgram function builds an OCaml program. It returns the array with all the targets for which it has defined the rules ($(name)$(EXE) and $(name).run and/or $(name).opt, depending on the NATIVE_ENABLED and BYTE_ENABLED variables).

OCamlProgram(<name>, <files>)

Additional variables used:
OCAML_LIBS 12.5.4.1
Additional libraries passed to the linker, without suffix. These files become dependencies of the target program.
OCAML_OTHER_LIBS 12.5.4.2
Additional libraries passed to the linker, without suffix. These files do not become dependencies of the target program.
OCAML_CLIBS 12.5.4.3
C libraries to pass to the linker.
OCAML_BYTE_LINK_FLAGS 12.5.3.6
Flags to pass to the bytecode linker.
OCAML_NATIVE_LINK_FLAGS 12.5.3.7
Flags to pass to the native code linker.
OCAML_LINK_FLAGS 12.5.3.8
Flags to pass to both linkers.

12.6.1.7  OCamlProgramCopy

The OCamlProgramCopy function copies an OCaml program to an install location.

OCamlProgramCopy(<tag>, <bindir>, <name>)

Additional variables used:
NATIVE_ENABLED
If NATIVE_ENABLED 12.5.2.20 is set, the native-code executable is copied; otherwise the byte-code executable is copied.

12.6.1.8  OCamlProgramInstall

The OCamlProgramInstall function builds a programs and copies it to an install location in one step.

OCamlProgramInstall(<tag>, <bindir>, <name>, <files>)

12.7  Building LATEX programs

12.7.1  Configuration variables

The following variables can be modified in your project.

12.7.1.1  LATEX

The LATEX command (default latex).

12.7.1.2  TETEX2_ENABLED

Flag indicating whether to use advanced LATEX options present in TeTeX v.2 (default value is determined the first time omake reads LaTeX.src and depends on the version of LATEX you have installed).

12.7.1.3  LATEXFLAGS

The LATEX flags (defaults depend on the TETEX2_ENABLED variable)

12.7.1.4  BIBTEX

The BibTeX command (default bibtex).

12.7.1.5  MAKEINDEX

The command to build an index (default makeindex).

12.7.1.6  DVIPS

The .dvi to PostScript converter (default dvips).

12.7.1.7  DVIPSFLAGS

Flags to pass to dvips (default -t letter).

12.7.1.8  DVIPDFM

The .dvi to .pdf converter (default dvipdfm).

12.7.1.9  DVIPDFMFLAGS

Flags to pass to dvipdfm (default -p letter).

12.7.1.10  PDFLATEX

The .latex to .pdf converter (default pdflatex).

12.7.1.11  PDFLATEXFLAGS

Flags to pass to pdflatex (default is empty).

12.7.1.12  USEPDFLATEX

Flag indicating whether to use pdflatex instead of dvipdfm to generate the .pdf document (default false).

12.7.2  Building LATEX documents

12.7.2.1  LaTeXDocument

The LaTeXDocument produces a LATEX document.

LaTeXDocument(<name>, <texfiles>)

The document <name> and <texfiles> are listed without suffixes. This function returns the filenames for the generated .ps and .pdf files.

Additional variables used:

12.7.2.2  TEXINPUTS

The LATEX search path (an array of directories, default is taken from the TEXINPUTS environment variable).

12.7.2.3  TEXDEPS

Additional files this document depends on.

12.7.2.4  TEXVARS

An array of names of the environment variables that are to be updated based on the value of OMake's TEXINPUTS variable. Defaults to TEXINPUTS BIBINPUTS BSTINPUTS.

12.7.2.5  TeXGeneratedFiles, LocalTeXGeneratedFiles

TeXGeneratedFiles(files)
LocalTeXGeneratedFiles(files)
The TeXGeneratedFiles and LocalTeXGeneratedFiles functions specify files that need to be generated before any LATEXfiles are scanned for dependencies. For example, if config.tex and inputs.tex are both generated files, specify:
    TeXGeneratedFiles(config.tex inputs.tex)
The TeXGeneratedFiles function is global — its arguments will be generated before any TeX files anywhere in the project are scanned for dependencies. The LocalTeXGeneratedFiles function follows the normal scoping rules of OMake.

12.7.2.6  LaTeXDocumentCopy

The LaTeXDocumentCopy copies the document to an install location.

LaTeXDocumentCopy(<tag>, <libdir>, <installname>, <docname>)

This function copies just the .pdf and .ps files.

12.7.2.7  LaTeXDocumentInstall

The LaTeXDocumentInstall builds a document and copies it to an install location in one step.

LaTeXDocumentInstall(<tag>, <libdir>, <installname>, <docname>, <files>)

12.8  Examining the dependency graph

12.8.0.8  dependencies, dependencies-all, dependencies-proper

   $(dependencies targets) : File Array
   $(dependencies-all targets) : File Array
   $(dependencies-proper targets) : File Array
      targets : File Array
   raises RuntimeException
The dependencies function returns the set of immediate dependencies of the given targets. This function can only be used within a rule body and all the arguments to the dependency function must also be dependencies of this rule. This restriction ensures that all the dependencies are known when this function is executed.

The dependencies-all function is similar, but it expands the dependencies recursively, returning all of the dependencies of a target, not just the immediate ones.

The dependencies-proper function returns all recursive dependencies, except the dependencies that are leaf targets. A leaf target is a target that has no dependencies and no build commands; a leaf target corresponds to a source file in the current project.

In all three functions, files that are not part of the current project are silently discarded.

One purpose of the dependencies-proper function is for “clean” targets. For example, one way to delete all intermediate files in a build is with a rule that uses the dependencies-proper. Note however, that the rule requires building the project before it can be deleted. For a shorter form, see the filter-proper-targets function.
    .PHONY: clean

    APP = ...     # the name of the target application
    clean: $(APP)
       rm $(dependencies-proper $(APP))

12.8.0.9  target

   $(target targets) : Target Array
      targets : File Sequence
   raises RuntimeException
The target function returns the Target object associated with each of the targets. See the Target object for more information.

12.8.0.10  find-build-targets

    $(find-build-targets tag) : Target Array
       tag : Succeeded | Failed
The find-build-targets allow the results of the build to be examined. The tag must specifies which targets are to be returned; the comparison is case-insensitive.
Succeeded
The list of targets that were built successfully.
Failed
The list of targets that could not be built.
These are used mainly in conjuction with the .BUILD_SUCCESS (Section 12.1) and .BUILD_FAILURE (Section 12.1) phony targets. For example, adding the following to your project OMakefile will print the number of targets that failed (if the build failed).
    .BUILD_FAILURE:
        echo "Failed target count: $(length $(find-build-targets Failed))"
Warning: this function is experimental and may not work in some situations.

12.8.0.11  project-directories

   $(project-directories) : Dir Array
The project-directories function returns the list of all directories that are considered to be part of the project.

To get the complete directory list, this function should be called from within a rule body.

12.8.0.12  rule

The rule function is called whenever a build rule is defined. It is unlikely that you will need to redefine this function, except in very exceptional cases.
   rule(multiple, target, pattern, sources, options, body) : Rule
      multiple : String
      target   : Sequence
      pattern  : Sequence
      sources  : Sequence
      options  : Array
      body     : Body
The rule function is called when a rule is evaluated.
multiple
A Boolean value indicating whether the rule was defined with a double colon ::.
target
The sequence of target names.
pattern
The sequence of patterns. This sequence will be empty for two-part rules.
sources
The sequence of dependencies.
options
An array of options. Each option is represented as a Map (Section 11.1.2) associating each specified option with a value.
body
The body expression of the rule.
Consider the following rule.
   target: pattern: sources :name1: option1 :name2: option2
      expr1
      expr2
This expression represents the following function call, where square brackets are used to indicate arrays, and the curly brackets represent a Map (Section 11.1.2).
   rule(false, target, pattern, sources,
        { $|:name1:| = option1; $|:name2:| = option2 }
        [expr1; expr2])
Jump to:    OMake Home • Guide Home • Guide (single-page) • Contents (short) • Contents (long)
Index:    All • Variables • Functions • Objects • Targets • Options