|  | Home | Libraries | People | FAQ | More | 
        In addition to generic error messages, b2 may emit one
        of the following:
      
warning: unknown rule X
        A rule was invoked that has not been defined with an "actions"
        or "rule" statement.
      
using N temp target(s)
Targets marked as being temporary (but nonetheless present) have been found.
updating N target(s)
Targets are out-of-date and will be updated.
can't find N target(s)
Source files can't be found and there are no actions to create them.
can't make N target(s)
Due to sources not being found, other targets cannot be made.
warning: X depends on itself
A target depends on itself either directly or through its sources.
don't know how to make X
A target is not present and no actions have been defined to create it.
X skipped for lack of Y
A source failed to build, and thus a target cannot be built.
warning: using independent target X
        A target that is not a dependency of any other target is being referenced
        with $(<) or $(>).
      
X removed
        B2 removed a partially built target after being interrupted.
      
        For parallel building to be successful, the dependencies among files must
        be properly spelled out, as targets tend to get built in a quickest-first
        ordering. Also, beware of un-parallelizable commands that drop fixed-named
        files into the current directory, like yacc(1) does.
      
        A poorly set $(JAMSHELL) is likely to result in silent
        failure.
      
This section is derived from the official Jam documentation and from experience using it and reading the Jambase rules. We repeat the information here mostly because it is essential to understanding and using Jam, but is not consolidated in a single place. Some of it is missing from the official documentation altogether. We hope it will be useful to anyone wishing to become familiar with Jam and the Boost build system.
rules" are actually simple procedural
            entities. Think of them as functions. Arguments are separated by colons.
          DEPENDS rule
            creates a link in the dependency graph between the named targets.
          INCLUDES
            rule is incorrect: INCLUDES targets1 :
            targets2 causes everything that depends
            on a member of targets1 to depend on all members
            of targets2. It does this in an odd way, by tacking
            targets2 onto a special tail section in the dependency
            list of everything in targets1. It seems to be OK
            to create circular dependencies this way; in fact, it appears to be the
            "right thing to do" when a single build action produces both
            targets1 and targets2.
          actions declared
            with the same name as the rule, the actions are added to the updating
            actions for the target identified by the rule's first argument. It is
            actually possible to invoke an undeclared rule if corresponding actions
            are declared: the rule is treated as empty.
          NOTFILE targets) are associated
            with paths in the file system through a process called binding. Binding
            is a process of searching for a file with the same name as the target
            (sans grist), based on the settings of the target-specific SEARCH
            and LOCATE variables.
          on a target. Target-specific variable values can usually
            not be read, and take effect only in the following contexts:
            on
                  the target named by the first argument (the target being updated).
                  Because Jam builds its entire dependency tree before executing
                  actions, Jam rules make target-specific variable settings as a
                  way of supplying parameters to the corresponding actions.
                SEARCH and LOCATE
                  variables, as described here.
                on the target named by the
                  rule's first argument (the source file being scanned).
                bind
            action modifier.
          test.exe" may
            be used by targets in separate subprojects, or for the debug and release
            variants of the "same" abstract target. Each distinct target
            bound to a file called "test.exe" has its own unique grist
            prefix. The Boost build system also takes full advantage of Jam's ability
            to divide strings on grist boundaries, sometimes concatenating multiple
            gristed elements at the beginning of a string. Grist is used instead
            of identifying targets with absolute paths for two reasons:
            MESSAGE ?\= starting jam... ; if $(MESSAGE) { ECHO The message is: $(MESSAGE) ; }If the user wants a specific message, he invokes jam with
"-sMESSAGE=message
            text". If he wants no message, he invokes jam with -sMESSAGE=
            and nothing at all is printed.
          -xvalue, and
                -x value.