This file has been translated from LaTeX by HeVeA.

Node: Subsection 13-6-2,	Next: Subsection 13-6-3,	Prev: Subsection 13-6-1,	Up: Section 13-6
  

13.6.2   Configuration variables for OCaml compilation
======================================================
  
  The following variables can be redefined in your project. 
 USE_OCAMLFIND
 Whether to use the `ocamlfind' utility
(default `false') 
 OCAMLC
 The OCaml bytecode compiler (default
`ocamlc.opt' if it exists and `USE_OCAMLFIND' is not set, otherwise
`ocamlc'). 
 OCAMLOPT
 The OCaml native-code compiler
(default `ocamlopt.opt' if it exists and `USE_OCAMLFIND' is not set,
otherwise `ocamlopt'). 
 CAMLP4
 The `camlp4' preprocessor (default
`camlp4'). 
 OCAMLLEX
 The OCaml lexer generator (default
`ocamllex'). 
 OCAMLLEXFLAGS
 The flags to pass to `ocamllex'
(default `-q'). 
 OCAMLYACC
 The OCaml parser generator (default
`ocamlyacc'). 
 OCAMLYACCFLAGS
 Additional options to pass to
`$(OCAMLYACC)'. 
 OCAMLDEP
 The OCaml dependency analyzer (default
`ocamldep'). 
 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). 
 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
13.6.5*Note Subsection 13-6-5:: for more information on
interactions between OMake, `OCAMLDEP' and generated files. Set to
`$(OCAMLDEP_MODULES_AVAILABLE)' by default. 
 OCAMLMKTOP
 The OCaml toploop compiler (default
`ocamlmktop'). 
 OCAMLLINK
 The OCaml bytecode linker (default
`$(OCAMLC)'). 
 OCAMLOPTLINK
 The OCaml native-code linker (default
`$(OCAMLOPT)'). 
 OCAMLINCLUDES
 Search path to pass to the OCaml
compilers (default `.'). The search path with the `-I' prefix is defined
by the `PREFIXED_OCAMLINCLUDES' variable. 
 OCAMLFIND
 The `ocamlfind' utility (default
`ocamlfind' if `USE_OCAMLFIND' is set, otherwise empty). 
 OCAMLFINDFLAGS
 The flags to pass to `ocamlfind'
(default empty, `USE_OCAMLFIND' must be set). 
 OCAMLPACKS
 Package names to pass to `ocamlfind'
(`USE_OCAMLFIND' must be set). 
 BYTE_ENABLED
 Flag indicating whether to use the
bytecode compiler (default `true', when no `ocamlopt' found, `false'
otherwise). 
 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. 
 MENHIR_ENABLED
 Define this as `true' if you wish to
use `menhir' instead of `ocamlyacc' (default `false'). 

Node: Subsection 13-6-3,	Next: Subsection 13-6-4,	Prev: Subsection 13-6-2,	Up: Section 13-6
  

13.6.3   OCaml command flags
============================
  
  The following variables specify additional options to be passed to the
OCaml tools. 
 OCAMLDEPFLAGS
 Flags to pass to `OCAMLDEP' and
`OCAMLDEP_MODULES'. 
 OCAMLPPFLAGS
 Flags to pass to `CAMLP4'. 
 OCAMLCFLAGS
 Flags to pass to the byte-code
compiler (default `-g'). 
 OCAMLOPTFLAGS
 Flags to pass to the native-code
compiler (default empty). 
 OCAMLFLAGS
 Flags to pass to either compiler
(default `-warn-error A'). 
 OCAML_BYTE_LINK_FLAGS
 Flags to pass to the byte-code linker
(default empty). 
 OCAML_NATIVE_LINK_FLAGS
 Flags to pass to the native-code
linker (default empty). 
 OCAML_LINK_FLAGS
 Flags to pass to either linker. 
 MENHIR_FLAGS
 Additional flags to pass to `menhir'. 

Node: Subsection 13-6-4,	Next: Subsection 13-6-5,	Prev: Subsection 13-6-3,	Up: Section 13-6
  

13.6.4   Library variables
==========================
  
  The following variables are used during linking.
 OCAML_LIBS
 Libraries to pass to the linker. These
libraries become dependencies of the link step. 
 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'. 
 OCAML_CLIBS
 C libraries to pass to the linker. 
 OCAML_LIB_FLAGS
 Extra flags for the library linker. 
 ABORT_ON_DEPENDENCY_ERRORS
 OCaml linker requires the OCaml files
to be listed in dependency order. Normally, all the functions presented
in this section will automatically sort the list of OCaml modules passed
in as the `<files>' argument. However, this variable is set to `true',
the order of the files passed into these function will be left as is,
but OMake will abort with an error message if the order is illegal.

Node: Subsection 13-6-5,	Next: Subsection 13-6-6,	Prev: Subsection 13-6-4,	Up: Section 13-6
  

13.6.5   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 'OCAMLDEP_MODULES_ENABLED' variable 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.
  

13.6.5.1   OCamlGeneratedFiles, LocalOCamlGeneratedFiles
--------------------------------------------------------
\@
name{function:LocalOCamlGeneratedFiles} 
<<OCamlGeneratedFiles(files)
  LocalOCamlGeneratedFiles(files)
>>
  
  When the 'OCAMLDEP_MODULES_ENABLED' variable 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 the 'OCAMLDEP_MODULES_ENABLED'
variable is true.
  

13.6.5.2   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
tell `ocamldep' to only find the free module names in a file and then
post-process the results internally.
  This automated functionality is enabled when the
'OCAMLDEP_MODULES_ENABLED' variable is set to `true'. By default,
'OCAMLDEP_MODULES_ENABLED' variable will be set to
`$(OCAMLDEP_MODULES_AVAILABLE)'.
  Note that the `ocamldep' functionality this relies upon is only
included in the OCaml version 3.10 and higher. Temporarily, we
distribute a bytecode version `ocamldep-omake' of the
appropriately modified `ocamldep'. The appropriate `ocamldep' will be
discovered automatically --- see and the 'OCAMLDEP_MODULES_AVAILABLE'
and 'OCAMLDEP_MODULES' variables will be set accordingly.

Node: Subsection 13-6-6,	Next: Section 13-7,	Prev: Subsection 13-6-5,	Up: Section 13-6
  

13.6.6   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/).
  
  
 - Menhir's explanations are believed to be understandable by mere
   humans. 
 - Menhir allows grammar specifications to be split over multiple files.
   It also allows several grammars to share a single set of tokens. 
 - Menhir is able to produce parsers that are parameterized by Objective
   Caml modules. 
 - Added by jyh With the `--infer' option, Menhir can typecheck the
   semantic actions in your grammar at generation time. 
  
  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)
>>
  

13.6.6.1   OCamlLibrary
-----------------------

  The `OCamlLibrary' function builds an OCaml library.
  `OCamlLibrary(<libname>, <files>)'
  The `<libname>' and `<files>' are listed without suffixes.
  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)
>>
  

13.6.6.2   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)
>>
  

13.6.6.3   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.

13.6.6.4   OCamlLibraryInstall
------------------------------

  The `OCamlLibraryInstall' function builds a library and copies it to
an install location in one step.
  `OCamlLibraryInstall(<tag>, <libdir>, <libname>, <files>)'

13.6.6.5   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'  Additional libraries passed to the linker, without
   suffix. These files become dependencies of the target program. 
 'OCAML_OTHER_LIBS'  Additional libraries passed to the linker, without
   suffix. These files do not become dependencies of the target program.
   
 'OCAML_CLIBS'  C libraries to pass to the linker. 
 'OCAML_BYTE_LINK_FLAGS'  Flags to pass to the bytecode linker. 
 'OCAML_NATIVE_LINK_FLAGS'  Flags to pass to the native code linker. 
 'OCAML_LINK_FLAGS'  Flags to pass to both linkers. 


13.6.6.6   OCamlProgramCopy
---------------------------

  The `OCamlProgramCopy' function copies an OCaml program to an install
location.
  `OCamlProgramCopy(<tag>, <bindir>, <name>)'
  Additional variables used: 
  
 NATIVE_ENABLED  If the 'NATIVE_ENABLED' variable is set, the
   native-code executable is copied; otherwise the byte-code executable
   is copied. 


13.6.6.7   OCamlProgramInstall
------------------------------

  The `OCamlProgramInstall' function builds a programs and copies it to
an install location in one step.
  `OCamlProgramInstall(<tag>, <bindir>, <name>, <files>)' 

Node: Section 13-7,	Next: Subsection 13-7-1,	Prev: Section 13-6,	Up: Chapter 13
  

13.7   Building LaTeX files
*=*=*=*=*=*=*=*=*=*=*=*=*=*

  
  OMake provides support for building LaTeX documents, including support
for automatically running BiBTex and for producing PostScript and PDF
files. In order to use the functions defined in this section, you need
to make sure the line 
<<open build/LaTeX
>>
  is present in your `OMakeroot' file.
* Menu:

* Subsection 13-7-1::	Configuration variables
* Subsection 13-7-2::	Building LaTeX documents


Node: Subsection 13-7-1,	Next: Subsection 13-7-2,	Prev: Section 13-7,	Up: Section 13-7
  

13.7.1   Configuration variables
================================
  
  The following variables can be modified in your project. 
 LATEX
 The LaTeX command (default `latex'). 
 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). 
 LATEXFLAGS
 The LaTeX flags (defaults depend on
the `TETEX2_ENABLED' variable) 
 BIBTEX
 The BibTeX command (default
`bibtex'). 
 MAKEINDEX
 The command to build an index
(default `makeindex'). 
 DVIPS
 The `.dvi' to PostScript converter
(default `dvips'). 
 DVIPSFLAGS
 Flags to pass to `dvips' (default `-t
letter'). 
 DVIPDFM
 The `.dvi' to `.pdf' converter
(default `dvipdfm'). 
 DVIPDFMFLAGS
 Flags to pass to `dvipdfm' (default
`-p letter'). 
 PDFLATEX
 The `.latex' to `.pdf' converter
(default `pdflatex'). 
 PDFLATEXFLAGS
 Flags to pass to pdflatex (default is
`$`(LATEXFLAGS)'). 
 USEPDFLATEX
 Flag indicating whether to use
pdflatex instead of dvipdfm to generate the `.pdf' document (default
`false'). 

Node: Subsection 13-7-2,	Next: Chapter 14,	Prev: Subsection 13-7-1,	Up: Section 13-7
  

13.7.2   Building LaTeX documents
=================================


13.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: 
 TEXINPUTS
 The LaTeX search path (an array of
directories, default is taken from the `TEXINPUTS' environment
variable). 
 TEXDEPS
 Additional files this document
depends on. 
 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'.

13.7.2.2   TeXGeneratedFiles, LocalTeXGeneratedFiles
----------------------------------------------------
\@na
me{function: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.
  

13.7.2.3   LaTeXDocumentCopy
----------------------------

  The `LaTeXDocumentCopy' copies the document to an install location.
  `LaTeXDocumentCopy(<tag>, <libdir>, <installname>, <docname>)'
  This function copies just the `.pdf' and `.ps' files.

13.7.2.4   LaTeXDocumentInstall
-------------------------------

  The `LaTeXDocumentInstall' builds a document and copies it to an
install location in one step.
  `LaTeXDocumentInstall(<tag>, <libdir>, <installname>, <docname>,
<files>)'  

Node: Chapter 14,	Next: Section 14-1,	Prev: Section 13-7,	Up: Top
  

Chapter 14     Autoconfiguration functions and variables
********************************************************
     OMake standard library provides a number of
functions and variables intended to help one write build specifications
that need to be capable of autoconfiguring itself to adjust to different
build environments.
* Menu:

* Section 14-1::	General-purpose autoconfiguration functions
* Section 14-2::	Translating 'autoconf' scripts
* Section 14-3::	Predefined configuration tests


Node: Section 14-1,	Next: Subsection 14-1-1,	Prev: Chapter 14,	Up: Chapter 14
  

14.1   General-purpose autoconfiguration functions
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

   The following general-purpose functions can be used to discover the
properties of your build environment in a fashion similar to the one
used by GNU autoconf tool you may be familiar with. It is recommended
that these function be used from an appropriate `static.' block (see
Section 4.14*Note Section 4-14:: for more information).
  In order to use the following general-purpose functions, you need to
have the line 
<<open configure/Configure
>>
  included in your `OMakefile' or `OMakeroot'. 
* Menu:

* Subsection 14-1-1::	ConfMsgChecking, ConfMsgResult
* Subsection 14-1-2::	ConfMsgWarn, ConfMsgError
* Subsection 14-1-3::	ConfMsgYesNo, ConfMsgFound
* Subsection 14-1-4::	TryCompileC, TryLinkC, TryRunC
* Subsection 14-1-5::	RunCProg
* Subsection 14-1-6::	CheckCHeader, VerboseCheckCHeader
* Subsection 14-1-7::	CheckCLib, VerboseCheckCLib
* Subsection 14-1-8::	CheckProg


Node: Subsection 14-1-1,	Next: Subsection 14-1-2,	Prev: Section 14-1,	Up: Section 14-1
  

14.1.1   ConfMsgChecking, ConfMsgResult
=======================================
\@name
{function:ConfMsgResult} 
<<ConfMsgChecking(<msg>)
  ...
  ConfMsgResult(<msg>)
>>
  The `ConfMsgChecking' function output message of the form `---
Checking <msg>... ' without any trailing newline. After the test
advertized by `ConfMsgChecking' is performed, the `ConfMsgResult'
function should be used to output the result.
  In certain cases users may want to redefine these function --- for
example, to use a different output formatting and/or to copy the
messages to a log file.
  Example: 
<<static. =
     ConfMsgChecking(which foo to use)
     foo = ...
     ConfMsgResult($(foo))
>>

Node: Subsection 14-1-2,	Next: Subsection 14-1-3,	Prev: Subsection 14-1-1,	Up: Section 14-1
  

14.1.2   ConfMsgWarn, ConfMsgError
==================================
 
<<ConfMsgWarn(<msg>)
  ConfMsgError(<msg>)
>>
  
  Print a warning or an error message respectively. `ConfMsgError' would
then abort OMake. 

Node: Subsection 14-1-3,	Next: Subsection 14-1-4,	Prev: Subsection 14-1-2,	Up: Section 14-1
  

14.1.3   ConfMsgYesNo, ConfMsgFound
===================================
 
<<flag = $(ConfMsgYesNo <bool expr>
  flag = $(ConfMsgFound <bool expr>
>>
  
  The `ConfMsgFound' function expects to receive a boolean flag
describing whether a test previously announced using the
'ConfMsgChecking' function found what it was looking for. `ConfMsgFound'
will output the appropriate result ("found" or "NOT found") using the
'ConfMsgResult' function and return its argument back.
  The `ConfMsgYesNo' function is similar, outputting a simple ("yes" or
"NO"). 

Node: Subsection 14-1-4,	Next: Subsection 14-1-5,	Prev: Subsection 14-1-3,	Up: Section 14-1
  

14.1.4   TryCompileC, TryLinkC, TryRunC
=======================================
 
<<success = $(TryCompileC <prog_text>)
  success = $(TryLinkC <prog_text>)
  success = $(TryRunC <prog_text>)
>>
  
  Given the text of a C program, the `TryCompileC', `TryLinkC', and
`TryRunC' functions would try to compile / compile and link / compile,
link, and run, the given program and return a boolean flag indicating
whether the attempt was successful.
  `TryCompileC' will use the 'CC', 'CFLAGS' and 'INCLUDES' variables  to
run the C compiler. `TryLinkC' and `TryRunC' will also use the 'LDFLAGS'
variable to run the C compiler and linker. However, the flags like
`/WX', `-Werror' and `-warn-error' will be not be passed to the
compiler, even if they occur in `CFLAGS'.
  These functions are silent and should normally be used with an
appropriate 'ConfMsgChecking' ... 'ConfMsgResult'. 

Node: Subsection 14-1-5,	Next: Subsection 14-1-6,	Prev: Subsection 14-1-4,	Up: Section 14-1
  

14.1.5   RunCProg
=================
 
<<output = $(RunCProg <prog>)
>>
  
  `RunCProg' is similar to the 'RunCProg' function, except that it
returns the output of the function (will return `false' if the program
fails to compile or run). 

Node: Subsection 14-1-6,	Next: Subsection 14-1-7,	Prev: Subsection 14-1-5,	Up: Section 14-1
  

14.1.6   CheckCHeader, VerboseCheckCHeader
==========================================
 
<<success = $(CheckCHeader <files>)
  success = $(VerboseCheckCHeader <files>)
>>
  
  Use the 'TryCompileC' function to check whether your C compiler can
locate and process the specified headers files. Will incude `<stdio.h>'
before including the header files.
  Both functions return a boolean value. The `CheckCHeader' function is
silent; the `VerboseCheckCHeader' function will use the
'ConfMsgChecking' and 'ConfMsgResult' functions to describe the test and
the outcome.
  Example: 
<<static. =
     NCURSES_H_AVAILABLE = $(VerboseCheckCHeader ncurses.h)
>>

Node: Subsection 14-1-7,	Next: Subsection 14-1-8,	Prev: Subsection 14-1-6,	Up: Section 14-1
  

14.1.7   CheckCLib, VerboseCheckCLib
====================================
 
<<success = $(CheckCLib <libs>, <functions>)
  success = $(VerboseCheckCLib <libs>, <functions>)
>>
  
  Use the 'TryLinkC' function to check whether your C compiler and
linker can find the named functions when linking with the named
libraries. Will pass the `<libs>' to the compiler using the `-l' flag.
  Both functions return a boolean value. The `CheckCLib' function is
silent; the `VerboseCheckCHeader' function will use the
'ConfMsgChecking' and 'ConfMsgResult' functions to describe the test and
the outcome.
  Example: 
<<static. =
      NCURSES_LIB_AVAILABLE = $(VerboseCheckCLib ncurses, initscr
setupterm tigetstr)
>>

Node: Subsection 14-1-8,	Next: Section 14-2,	Prev: Subsection 14-1-7,	Up: Section 14-1
  

14.1.8   CheckProg
==================
 `success =
$(CheckProg <prog>)'
  Checks whether the program `<prog>' exists in your path. Will use the
'ConfMsgChecking' and 'ConfMsgResult' functions to describe the test and
the outcome.

Node: Section 14-2,	Next: Section 14-3,	Prev: Section 14-1,	Up: Chapter 14
  

14.2   Translating 'autoconf' scripts
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

   Some of the functions described above are very similar to the ones
present in `autoconf'. Below is a brief translation table for such
functions. 
  
  'AC_MSG_CHECKING' is very similar to
   'ConfMsgChecking' function. 
  'AC_MSG_RESULT' is very similar to 'ConfMsgResult'
   function. 
  'AC_MSG_WARN' is very similar to 'ConfMsgWarn'
   function. 
  'AC_MSG_ERROR' is very similar to 'ConfMsgError'
   function. 
  'AC_TRY_COMPILE' is somewhat similar to
   'TryCompileC' function, except the 'TryCompileC' function returns a
   boolean value and only works for `C'. Similarly, 
  'AC_TRY_LINK' is approximated by 'TryLinkC'
   function, and 
  'AC_TRY_RUN' is approximated by 'TryRunC' function.
   
  

Node: Section 14-3,	Next: Subsection 14-3-1,	Prev: Section 14-2,	Up: Chapter 14
  

14.3   Predefined configuration tests
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

   A number of configuration tests are already included in the standard
library. In order to use them in your project, simply `open' (see
Section 4.7*Note Section 4-7::) the corresponding build file in
your `OMakefile' and the tests will run the first time OMake is
executed. Note that it is not a problem to `open' these files from more
than one place in your project --- if you do that, the test will still
run only once. 
* Menu:

* Subsection 14-3-1::	NCurses library configuration
* Subsection 14-3-2::	ReadLine library configuration
* Subsection 14-3-3::	Snprintf configuration


Node: Subsection 14-3-1,	Next: Subsection 14-3-2,	Prev: Section 14-3,	Up: Section 14-3
  

14.3.1   NCurses library configuration
======================================
   Add `open configure/ncurses' line to your `OMakefile' to get access
to the following autoconfiguration variables. 
 NCURSES_AVAILABLE
 A boolean flag that would be set when
both the `curses.h' header, the `term.h' header, and the `ncurses'
library very found.
 NCURSES_TERMH_IN_NCURSES
 A boolean flag that would be set when
`term.h' has to be included as `<ncurses/term.h>' instead of `<term.h>'.
 NCURSES_CFLAGS
 The `CFLAGS' to use when compiling
ncurses code. Will include `-DNCURSES' and `-DTERMH_IN_NCURSES',
respectively when `NCURSES_AVAILABLE' and `NCURSES_TERMH_IN_NCURSES' are
true.
 NCURSES_CLIBS
 The `LDFLAGS' to use when linking
ncurses code. Will normally contain `-lncurses' when ncurses is found
and remain empty otherwise. 

Node: Subsection 14-3-2,	Next: Subsection 14-3-3,	Prev: Subsection 14-3-1,	Up: Section 14-3
  

14.3.2   ReadLine library configuration
=======================================
   Add `open configure/readline' line to your `OMakefile' to get access
to the following autoconfiguration variables. 
 READLINE_AVAILABLE
 A boolean flag that would be set when
both the `readline/readline.h' header, the `readline/history.h' header,
and the `readline' library very found.
 READLINE_GNU
 A boolean flag that would be set when
the GNU version of the readline library is found (as opposed to the BSD
one).
 READLINE_CFLAGS
 The `CFLAGS' to use when compiling
readline code. Will include `-DREADLINE_ENABLED' and `-DREADLINE_GNU',
respectively when `READLINE_AVAILABLE' and `READLINE_GNU' are true.
 READLINE_CLIBS
 The `LDFLAGS' to use when linking
readline code. Will normally contain `-lncurses -lreadline' when
readline is found and remain empty otherwise. 

Node: Subsection 14-3-3,	Next: Chapter 15,	Prev: Subsection 14-3-2,	Up: Section 14-3
  

14.3.3   Snprintf configuration
===============================
   Add `open configure/snprintf' line to your `OMakefile' to get access
to the following autoconfiguration variables. 
 SNPRINTF_AVAILABLE
 A boolean flag telling whether the
snprintf function is available in the standard C library.
   

Node: Chapter 15,	Next: Section 15-1,	Prev: Section 14-3,	Up: Top
  

Chapter 15     The OSH shell
****************************
    
  OMake also includes a standalone command-line interpreter osh that can
be used as an interactive shell. The shell uses the same syntax, and
provides the same features on all platforms omake supports, including
Win32.
* Menu:

* Section 15-1::	Startup
* Section 15-2::	Aliases
* Section 15-3::	Interactive syntax


Node: Section 15-1,	Next: Section 15-2,	Prev: Chapter 15,	Up: Chapter 15
  

15.1   Startup
*=*=*=*=*=*=*=

  
  On startup, osh reads the file `~/.oshrc' if it exists. The syntax of
this file is the same as an OMakefile. The following additional
variables are significant.
 prompt
 The `prompt' variable specifies the
command-line prompt. It can be a simple string.
<<    prompt = osh>
>>
  
  Or you may choose to define it as a function of no arguments.
<<    prompt() =
          return $"<$(USER):$(HOST) $(homename $(CWD))>"
>>
  
  An example of the latter prompt is as follows.
<<    <jyh:kenai.yapper.org ~>cd links/omake
      <jyh:kenai.yapper.org ~/links/omake>
>>
  
  If you include any "invisible" text in the prompt (such as various
terminal escape sequences), they must be wrapped using the
'prompt-invisible' function. For example, to create a bold prompt on
terminals that support it, you can use the following. 
<<    prompt =
         bold-begin = $(prompt-invisible $(tgetstr bold))
         bold-end = $(prompt-invisible $(tgetstr sgr0))
         value $(bold-begin)$"osh>"$(bold-end)
>>
  
 ignoreeof
 If the `ignoreeof' is `true', then
`osh' will not exit on a terminal end-of-file (usually `^D' on Unix
systems).

Node: Section 15-2,	Next: Section 15-3,	Prev: Section 15-1,	Up: Chapter 15
  

15.2   Aliases
*=*=*=*=*=*=*=

   
  Command aliases are defined by adding functions to the `Shell.'
object. The following alias adds the `-AF' option to the `ls' command.
<<    Shell. +=
         ls(argv) =
            "ls" -AF $(argv)
>>
  
  Quoted commands do not undergo alias expansion. The quotation `"ls"'
prevents the alias from being recursive.

Node: Section 15-3,	Next: Appendix A,	Prev: Section 15-2,	Up: Chapter 15
  

15.3   Interactive syntax
*=*=*=*=*=*=*=*=*=*=*=*=*

  
  The interactive syntax in `osh' is the same as the syntax of an
`OMakefile', with one exception in regard to indentation. The line
before an indented block must have a colon at the end of the line. A
block is terminated with a `.' on a line by itself, or `^D'. In the
following example, the first line `if true' has no body, because there
is no colon.
<<   # The following if has no body
     osh>if true
     # The following if has a body
     osh>if true:
     if>       if true:
     if>          println(Hello world)
     if>          .
     Hello world
>>
  
  Note that `osh' makes some effort to modify the prompt while in an
indented body, and it auto-indents the text.
  The colon signifier is also allowed in files, although it is not
required.
   

Node: Appendix A,	Next: Section A-1,	Prev: Chapter 15,	Up: Top
  

Appendix A     Synopsis
***********************
    
  omake [-j <count>] [-k] [-p] [-P] [-n] [-s] [-S] [-w] [-t] [-u] [-U]
[-R] [--verbose] [--project] [--depend] [--progress] [--print-status]
[--print-exit] [--print-dependencies] [--show-dependencies <target>]
[--all-dependencies] [--verbose-dependencies] [--force-dotomake]
[--dotomake <dir>] [--flush-includes] [--configure] [--save-interval
<seconds>] [--install] [--install-all] [--install-force] [--version]
[--absname] [--output-normal] [--output-postpone] [--output-only-errors]
[--output-at-end] filename... [var-definition...]
* Menu:

* Section A-1::	General usage
* Section A-2::	Output control
* Section A-3::	Build options
* Section A-4::	Additional options
* Section A-5::	Environment variables
* Section A-6::	Functions
* Section A-7::	Option processing
* Section A-8::	.omakerc


Node: Section A-1,	Next: Section A-2,	Prev: Appendix A,	Up: Appendix A
  

A.1   General usage
*=*=*=*=*=*=*=*=*=*

  
  For Boolean options (for example, `-s', `--progress', etc.) the option
can include a prefix `--no', which inverts the usual sense of the
option. For example, the option `--progress' means "print a progress
bar," while the option `--no--progress' means "do not print a progress
bar."
  If multiple instances of an option are specified, the final option
determines the behavior of OMake. In the following command line, the
final `--no-S' cancels the earlier `-S'.
<<    % omake -S --progress --no-S
>>
  

Node: Section A-2,	Next: Subsection A-2-1,	Prev: Section A-1,	Up: Appendix A
  

A.2   Output control
*=*=*=*=*=*=*=*=*=*=

  
* Menu:

* Subsection A-2-1::	-s
* Subsection A-2-2::	-S
* Subsection A-2-3::	-w
* Subsection A-2-4::	--progress
* Subsection A-2-5::	--print-status
* Subsection A-2-6::	--print-exit
* Subsection A-2-7::	--verbose
* Subsection A-2-8::	--output-normal
* Subsection A-2-9::	--output-postpone
* Subsection A-2-10::	--output-only-errors
* Subsection A-2-11::	--output-at-end
* Subsection A-2-12::	-o


Node: Subsection A-2-1,	Next: Subsection A-2-2,	Prev: Section A-2,	Up: Section A-2
  

A.2.1   -s
==========
 `-s'
  Never not print commands as they are executed (be "silent").

Node: Subsection A-2-2,	Next: Subsection A-2-3,	Prev: Subsection A-2-1,	Up: Section A-2
  

A.2.2   -S
==========
 `-S'
  Do not print commands as they are executed unless they produce output
and/or fail. This is the default.

Node: Subsection A-2-3,	Next: Subsection A-2-4,	Prev: Subsection A-2-2,	Up: Section A-2
  

A.2.3   -w
==========
 `-w'
  Print directory information in make format as commands are executed.
This is mainly useful for editors that expect make-style directory
information for determining the location of errors.

Node: Subsection A-2-4,	Next: Subsection A-2-5,	Prev: Subsection A-2-3,	Up: Section A-2
  

A.2.4   --progress
==================
 `--progress'
  Print a progress indicator. This option is enabled by default when the
OMake's output (`stdout') is on a terminal and disabled by default
(except on Windows) when the OMake's output is redirected.

Node: Subsection A-2-5,	Next: Subsection A-2-6,	Prev: Subsection A-2-4,	Up: Section A-2
  

A.2.5   --print-status
======================

`--print-status'
  Print status lines (the `+' and `-' lines).

Node: Subsection A-2-6,	Next: Subsection A-2-7,	Prev: Subsection A-2-5,	Up: Section A-2
  

A.2.6   --print-exit
====================

`--print-exit'
  Print termination codes when commands complete.

Node: Subsection A-2-7,	Next: Subsection A-2-8,	Prev: Subsection A-2-6,	Up: Section A-2
  

A.2.7   --verbose
=================
 `--verbose'
  Make OMake very verbose. This option is equivalent to `--no-S
--print-status --print-exit VERBOSE=true'

Node: Subsection A-2-8,	Next: Subsection A-2-9,	Prev: Subsection A-2-7,	Up: Section A-2
  

A.2.8   --output-normal
=======================

`--output-normal'
  As rule commands are executed, relay their output to the OMake output
right away. This is enabled by default, unless `--output-postpone' or
`--output-only-errors' is enabled.

Node: Subsection A-2-9,	Next: Subsection A-2-10,	Prev: Subsection A-2-8,	Up: Section A-2
  

A.2.9   --output-postpone
=========================

`--output-postpone'
  When a rule finishes, print the output as a single block. This is
useful in combination `-j' option (see Section
A.3.12*Note Subsection A-3-12::), where the output of multiple subprocesses
can be garbled. The diversion is printed as a single coherent unit.
  Note that enabling `--output-postpone' will by default disable the
`--output-normal' option. This might be problematic if you have a
command that decides to ask for interactive input. If the
`--output-postpone' is enabled, but the `--output-normal' is not, the
prompt of such a command will not be visible and it may be hard to
figure out why the build appears "stuck". You might also consider using
the `--progress' flag (see Section A.2.4*Note Subsection A-2-4::)
so that you can see when the build is active. 

Node: Subsection A-2-10,	Next: Subsection A-2-11,	Prev: Subsection A-2-9,	Up: Section A-2
  

A.2.10   --output-only-errors
=============================

`--output-only-errors' 
  Similar to `--output-postpone', except that the postponed output from
commands that were successful will be discarded. This can be useful in
reducing unwanted output so that you can concentrate on any errors.

Node: Subsection A-2-11,	Next: Subsection A-2-12,	Prev: Subsection A-2-10,	Up: Section A-2
  

A.2.11   --output-at-end
========================

`--output-at-end'
  If any rules/commands fail, re-print the output of the failed commands
when OMake finishes the build. This is especially useful when any of the
`-k', `-p', or `-P' options are enabled.
  This option is off by default. However, when `-k' is enabled ---
either explicitly or via one of the `-p'/`-P' options ---
`--output-at-end' will be enabled by default.

Node: Subsection A-2-12,	Next: Section A-3,	Prev: Subsection A-2-11,	Up: Section A-2
  

A.2.12   -o
===========
 `-o [01jwWpPxXsS]'
  For brevity, the `-o' option is also provided to duplicate the above
output options. The `-o' option takes a argument consisting of a
sequence of characters. The characters are read from left-to-right; each
specifies a set of output options. In general, an uppercase character
turns the option on; a lowercase character turns the option off.
  
  
 0  Equivalent to `-s --output-only-errors --no-progress'
 This option specifies that `omake' should be as quiet as possible. If
   any errors occur during the build, the output is delayed until the
   build terminates. Output from successful commands is discarded.
 
 1  Equivalent to `-S --progress --output-only-errors'
 This is a slightly more relaxed version of "quiet" output. The output
   from successful commands is discarded. The output from failed
   commands is printed immediately after the command complete. The
   output from failed commands is displayed twice: once immediately
   after the command completes, and again when the build completes. A
   progress bar is displayed so that you know when the build is active.
   Include the ``p'' option if you want to turn off the progress bar
   (for example `omake -o 1p').
 
 2  Equivalent to `--progress --output-postpone'
 The is even more relaxed, output from successful commands is printed.
   This is often useful for deinterleaving the output when using `-j'.
 
 W  Equivalent to `-w' 
 w  Equivalent to `--no-w' 
 P  Equivalent to `--progress' 
 p  Equivalent to `--no--progress' 
 X  Equivalent to `--print-exit' 
 x  Equivalent to `--no-print-exit' 
 S  Equivalent to `-S' 
 s  Equivalent to `--no-S' 
  

Node: Section A-3,	Next: Subsection A-3-1,	Prev: Section A-2,	Up: Appendix A
  

A.3   Build options
*=*=*=*=*=*=*=*=*=*

  
* Menu:

* Subsection A-3-1::	-k
* Subsection A-3-2::	-n
* Subsection A-3-3::	-p
* Subsection A-3-4::	-P
* Subsection A-3-5::	-R
* Subsection A-3-6::	-t
* Subsection A-3-7::	-U
* Subsection A-3-8::	--depend
* Subsection A-3-9::	--configure
* Subsection A-3-10::	--force-dotomake
* Subsection A-3-11::	--dotomake
* Subsection A-3-12::	-j
* Subsection A-3-13::	--print-dependencies
* Subsection A-3-14::	--show-dependencies
* Subsection A-3-15::	--all-dependencies
* Subsection A-3-16::	--verbose-dependencies
* Subsection A-3-17::	--install
* Subsection A-3-18::	--install-all
* Subsection A-3-19::	--install-force
* Subsection A-3-20::	--absname
* Subsection A-3-21::	variable definition


Node: Subsection A-3-1,	Next: Subsection A-3-2,	Prev: Section A-3,	Up: Section A-3
  

A.3.1   -k
==========
 `-k'
  Do not abort when a build command fails; continue to build as much of
the project as possible. This option is implied by both `-p' and `-P'
options. In turn, this option would imply the `--output-at-end' option.

Node: Subsection A-3-2,	Next: Subsection A-3-3,	Prev: Subsection A-3-1,	Up: Section A-3
  

A.3.2   -n
==========
 `-n'
  This can be used to see what would happen if the project were to be
built.

Node: Subsection A-3-3,	Next: Subsection A-3-4,	Prev: Subsection A-3-2,	Up: Section A-3
  

A.3.3   -p
==========
 `-p'
  Watch the filesystem for changes, and continue the build until it
succeeds. If this option is specified, omake will restart the build
whenever source files are modified. Implies -k.

Node: Subsection A-3-4,	Next: Subsection A-3-5,	Prev: Subsection A-3-3,	Up: Section A-3
  

A.3.4   -P
==========
 `-P'
  Watch the filesystem for changes forever. If this option is specified,
omake will restart the build whenever source files are modified. Implies
-k.

Node: Subsection A-3-5,	Next: Subsection A-3-6,	Prev: Subsection A-3-4,	Up: Section A-3
  

A.3.5   -R
==========
 `-R'
  Ignore the current directory and build the project from its root
directory. When omake is run in a subdirectory of a project and no
explicit targets are given on the command line, it would normally only
build files within the current directory and its subdirectories (more
precisely, it builds all the `.DEFAULT' targets in the current directory
and its subdirectories). If the -R option is specified, the build is
performed as if omake were run in the project root.
  In other words, with the `-R' option, all the relative targets
specified on the command line will be taken relative to the project root
(instead of relative to the current directory). When no targets are
given on the command line, all the `.DEFAULT' targets in the project
will be built (regardless of the current directory).

Node: Subsection A-3-6,	Next: Subsection A-3-7,	Prev: Subsection A-3-5,	Up: Section A-3
  

A.3.6   -t
==========
 `-t'
  Update the omake database to force the project to be considered
up-to-date.

Node: Subsection A-3-7,	Next: Subsection A-3-8,	Prev: Subsection A-3-6,	Up: Section A-3
  

A.3.7   -U
==========
 `-U'
  Do not trust cached build information. This will force the entire
project to be rebuilt.

Node: Subsection A-3-8,	Next: Subsection A-3-9,	Prev: Subsection A-3-7,	Up: Section A-3
  

A.3.8   --depend
================
 `--depend'
  Do not trust cached dependency information. This will force files to
be rescanned for dependency information.

Node: Subsection A-3-9,	Next: Subsection A-3-10,	Prev: Subsection A-3-8,	Up: Section A-3
  

A.3.9   --configure
===================

`--configure'
  Re-run `static.' sections of the included omake files, instead of
trusting the cached results.

Node: Subsection A-3-10,	Next: Subsection A-3-11,	Prev: Subsection A-3-9,	Up: Section A-3
  

A.3.10   --force-dotomake
=========================

`--force-dotomake'
  Always use the `$HOME/.omake' for the `.omc' cache files.

Node: Subsection A-3-11,	Next: Subsection A-3-12,	Prev: Subsection A-3-10,	Up: Section A-3
  

A.3.11   --dotomake
===================
 `--dotomake
<dir>'
  Use the specified directory instead of the `$HOME/.omake' for the
placement of the `.omc' cache files.

Node: Subsection A-3-12,	Next: Subsection A-3-13,	Prev: Subsection A-3-11,	Up: Section A-3
  

A.3.12   -j
===========
 `-j <count>'
  Run multiple build commands in parallel. The count specifies a bound
on the number of commands to run simultaneously. In addition, the count
may specify servers for remote execution of commands in the form
`server=count'. For example, the option `-j
2:small.host.org=1:large.host.org=4' would specify that up to 2 jobs can
be executed locally, 1 on the server `small.host.org' and 4 on
`large.host.org'. Each remote server must use the same filesystem
location for the project.
  Remote execution is currently an experimental feature. Remote
filesystems like NFS do not provide adequate file consistency for this
to work.

Node: Subsection A-3-13,	Next: Subsection A-3-14,	Prev: Subsection A-3-12,	Up: Section A-3
  

A.3.13   --print-dependencies
=============================

`--print-dependencies'
  Print dependency information for the targets on the command line.

Node: Subsection A-3-14,	Next: Subsection A-3-15,	Prev: Subsection A-3-13,	Up: Section A-3
  

A.3.14   --show-dependencies
============================

`--show-dependencies <target>'
  Print dependency information if the `target' is built.

Node: Subsection A-3-15,	Next: Subsection A-3-16,	Prev: Subsection A-3-14,	Up: Section A-3
  

A.3.15   --all-dependencies
===========================

`--all-dependencies'
  If either of the options --print-dependencies or --show-dependencies
is in effect, print transitive dependencies. That is, print all
dependencies recursively. If neither option --print-dependencies,
--show-dependencies is specified, this option has no effect.

Node: Subsection A-3-16,	Next: Subsection A-3-17,	Prev: Subsection A-3-15,	Up: Section A-3
  

A.3.16   --verbose-dependencies
===============================

`--verbose-dependencies'
  If either of the options --print-dependencies or --show-dependencies
is in effect, also print listings for each dependency. The output is
very verbose, consider redirecting to a file. If neither option
--print-dependencies, --show-dependencies is specified, this option has
no effect.

Node: Subsection A-3-17,	Next: Subsection A-3-18,	Prev: Subsection A-3-16,	Up: Section A-3
  

A.3.17   --install
==================
 `--install'
  Install default files OMakefile and OMakeroot into the current
directory. You would typically do this to start a project in the current
directory.

Node: Subsection A-3-18,	Next: Subsection A-3-19,	Prev: Subsection A-3-17,	Up: Section A-3
  

A.3.18   --install-all
======================

`--install-all'
  In addition to installing files OMakefile and OMakeroot, install
default OMakefiles into each subdirectory of the current directory.
cvs(1) rules are used for filtering the subdirectory list. For example,
OMakefiles are not copied into directories called `CVS', `RCCS', etc.

Node: Subsection A-3-19,	Next: Subsection A-3-20,	Prev: Subsection A-3-18,	Up: Section A-3
  

A.3.19   --install-force
========================

`--install-force'
  Normally, omake will prompt before it overwrites any existing
OMakefile. If this option is given, all files are forcibly overwritten
without prompting.

Node: Subsection A-3-20,	Next: Subsection A-3-21,	Prev: Subsection A-3-19,	Up: Section A-3
  

A.3.20   --absname
==================
 `--absname'
  Filenames should expand to absolute pathnames.
  N.B. This is an experimental option. It may become deprecated.

Node: Subsection A-3-21,	Next: Section A-4,	Prev: Subsection A-3-20,	Up: Section A-3
  

A.3.21   variable definition
============================

`name=[value]'
  omake variables can also be defined on the command line in the form
`name=value'. For example, the `CFLAGS' variable might be defined on the
command line with the argument `CFLAGS="-Wall -g"'.

Node: Section A-4,	Next: Section A-5,	Prev: Section A-3,	Up: Appendix A
  

A.4   Additional options
*=*=*=*=*=*=*=*=*=*=*=*=

  
  In addition, omake supports a number of debugging flags on the command
line. Run `omake --help' to get a summary of these flags.

Node: Section A-5,	Next: Subsection A-5-1,	Prev: Section A-4,	Up: Appendix A
  

A.5   Environment variables
*=*=*=*=*=*=*=*=*=*=*=*=*=*

  
* Menu:

* Subsection A-5-1::	OMAKEFLAGS
* Subsection A-5-2::	OMAKELIB


Node: Subsection A-5-1,	Next: Subsection A-5-2,	Prev: Section A-5,	Up: Section A-5
  

A.5.1   OMAKEFLAGS
==================
   
  If defines, the `OMAKEFLAGS' should specify a set of options exactly
as they are specified on the command line.

Node: Subsection A-5-2,	Next: Section A-6,	Prev: Subsection A-5-1,	Up: Section A-5
  

A.5.2   OMAKELIB
================
   
  If defined, the `OMAKELIB' environment variable should refer to the
installed location of the OMake standard library. This is the directory
that contains `Pervasives.om' etc. On a Unix system, this is often
`/usr/lib/omake' or `/usr/local/lib/omake', and on Win32 systems it is
often `c:\Program Files\OMake\lib'.
  If not defined, `omake' uses the default configured location. You
should normally leave this unset.

Node: Section A-6,	Next: Subsection A-6-1,	Prev: Section A-5,	Up: Appendix A
  

A.6   Functions
*=*=*=*=*=*=*=*

  
* Menu:

* Subsection A-6-1::	OMakeFlags


Node: Subsection A-6-1,	Next: Section A-7,	Prev: Section A-6,	Up: Section A-6
  

A.6.1   OMakeFlags
==================
  
  The `OMakeFlags' function can be used within an `OMakefile' to modify
the set of options. The options should be specified exactly as they are
on the command line. For example, if you want some specific project to
be silent and display a progress bar, you can add the following line to
your `OMakefile'.
<<    OMakeFlags(-S --progress)
>>
  
  For options where it makes sense, the options are scoped like
variables. For example, if you want OMake to be silent for a single rule
(instead of for the entire project), you can use scoping the restrict
the range of the option.
<<    section
          # Do not display command output when foo is constructed
          OMakeFlags(-S)
  
          foo: fee
             echo "This is a generated file" > foo
             cat fee >> foo
             chmod 555 foo
>>
  

Node: Section A-7,	Next: Section A-8,	Prev: Section A-6,	Up: Appendix A
  

A.7   Option processing
*=*=*=*=*=*=*=*=*=*=*=*

  
  When `omake' is invoked, the options are processed in the following
order.
  
  
 1. All options specified by the `OMAKEFLAGS' environment variable are
   defined globally. 
 2. All options from the command line are defined globally. 
 3. Any individual calls the the `OMakeFlags' function modify the
   options locally. 
  

Node: Section A-8,	Next: Appendix B,	Prev: Section A-7,	Up: Appendix A
  

A.8   .omakerc
*=*=*=*=*=*=*=

    
  If the `$(HOME)/.omakerc' exists, it is read before any of the
`OMakefiles' in your project. The `.omakerc' file is frequently used for
user-specific customization. For example, instead of defining the
`OMAKEFLAGS' environment variable, you could add a line to your
`.omakerc'.
<<    $(HOME)/.omakerc:
          # My private options
          OMakeFlags(-S --progress)
>>
  
   

Node: Appendix B,	Next: Section B-1,	Prev: Appendix A,	Up: Top
  

Appendix B     OMake grammar
****************************
    
* Menu:

* Section B-1::	OMake lexical conventions
* Section B-2::	The OMake grammar
* Section B-3::	Dollar modifiers


Node: Section B-1,	Next: Subsection B-1-1,	Prev: Appendix B,	Up: Appendix B
  

B.1   OMake lexical conventions
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

  
  The OMake language is based on the language for GNU/BSD make, where
there are few lexical conventions. Strictly speaking, there are no
keywords, and few special symbols.
* Menu:

* Subsection B-1-1::	Comments
* Subsection B-1-2::	Special characters
* Subsection B-1-3::	Identifiers
* Subsection B-1-4::	Command identifiers
* Subsection B-1-5::	Variable references
* Subsection B-1-6::	String constants

