Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

ftjam(1) [debian man page]

ftjam(1)						      General Commands Manual							  ftjam(1)

NAME
Jam/MR -- Make(1) Redux SYNOPSIS
ftjam [-a] [-g] [-n] [-q] [-v] [-d debug] [-f jambase] [-j jobs] [-o actionsfile] [-s var=value] [-t target] [target ...] DESCRIPTION
Jam is a program construction tool, like make(1). Jam recursively builds target files from source files, using dependency information and updating actions expressed in the Jambase file, which is written in jam's own interpreted language. The default Jambase is compiled into jam and provides a boilerplate for common use, relying on a user-provide file "Jamfile" to enumerate actual targets and sources. OPTIONS
-a Build all targets anyway, even if they are up-to-date. -d n Enable cummulative debugging levels from 1 to n. Interesting values are: 1 Show actions (the default) 2 Show "quiet" actions and display all action text 3 Show dependency analysis, and target/source timestamps/paths 4 Show shell arguments 5 Show rule invocations and variable expansions 6 Show directory/header file/archive scans 7 Show variable settings 8 Show variable fetches 9 Show variable manipulation, scanner tokens -d +n Enable debugging level n. -d 0 Turn off all debugging levels. Only errors are not suppressed. -f jambase Read jambase instead of using the built-in Jambase. Only one -f flag is permitted, but the jambase may explicitly include other files. -g Build targets with the newest sources first, rather than in the order of appearance in the Jambase/Jamfiles. -j n Run up to n shell commands concurrently (UNIX and NT only). The default is 1. -n Don't actually execute the updating actions, but do everything else. This changes the debug level default to -d2. -o file Write the updating actions to the specified file instead of running them (or outputting them, as on the Mac). -q Quit quickly (as if an interrupt was received) as soon as any target build fails. -s var=value Set the variable var to value, overriding both internal variables and variables imported from the environment. -t target Rebuild target and everything that depends on it, even if it is up-to-date. -v Print the version of ftjam and exit. SEE ALSO
ftjam is documented fully in HTML pages available on Debian systems from /usr/share/doc/ftjam/Jam.html. AUTHOR
This manual page was created by Yann Dirson dirson@debian.org from the Jam.html documentation, for the Debian GNU/Linux system (but may be used by others). ftjam(1)

Check Out this Related Man Page

bjam(1) 						      General Commands Manual							   bjam(1)

NAME
bjam - Command-line utility to build Boost-related C++ projects with Boost.Build SYNOPSIS
bjam [-a] [-dx] [-fx] [-jx] [-lx] [-n] [-ox] [-px] [-q] [-sx=y] [-tx] [-v] [--x] bjam accepts the following options: -a Build all targets, even if they are current -dx Set the debug level to x (0-9) -fx Read x instead of Jambase -jx Run up to x shell commands concurrently -lx Limit actions to x number of seconds after which they are stopped -n Don't actually execute the updating actions -ox Write the updating actions to file x -px x=0, pipes action stdout and stderr merged into action output -q Quit quickly as soon as a target fails -sx=y Set variable x=y, overriding environment -tx Rebuild x, even if it is up-to-date -v Print the version of jam and exit --x Option is ignored DESCRIPTION
This section provides the information necessary to create your own projects using Boost.Build The information provided here is relatively high-level, and Chapter 6, Reference as well as the on-line help system must be used to obtain low-level documentation (see --help) Boost.Build actually consists of two parts - Boost.Jam, a build engine with its own interpreted language, and Boost.Build itself, implemented in Boost.Jam's language. The chain of events when you type bjam on the command line is as follows: o Boost.Jam tries to find Boost.Build and loads the top-level module. The exact process is described in the section called "Initialization" o The top-level module loads user-defined configuration files, user-config.jam and site-config.jam, which define available toolsets o The Jamfile in the current directory is read That in turn might cause reading of further Jamfiles. As a result, a tree of projects is created, with targets inside projects o Finally, using the build request specified on the command line, Boost.Build decides which targets should be built and how. That information is passed back to Boost.Jam, which takes care of actually running the scheduled build action commands So, to be able to successfully use Boost.Build, you need to know only four things: o How to configure Boost.Build (http://www.boost.org/boost-build2/doc/html/bbv2/overview/configuration.html) o How to declare targets in Jamfiles (http://www.boost.org/boost-build2/doc/html/bbv2/overview/targets.html) o How the build process works (http://www.boost.org/boost-build2/doc/html/bbv2/overview/build_process.html) Some Basics about the Boost.Jam language. See the section called "Boost.Jam Language" (http://www.boost.org/boost- build2/doc/html/bbv2/overview/jam_language.html) CONCEPTS
Boost.Build has a few unique concepts that are introduced in this section. The best way to explain the concepts is by comparison with more classical build tools When using any flavour of make, you directly specify targets and commands that are used to create them from other target. The below example creates a.o from a.c using a hardcoded compiler invocation command a.o: a.c g++ -o a.o -g a.c This is rather low-level description mechanism and it is hard to adjust commands, options, and sets of created targets depending on the used compiler and operating system. To improve portability, most modern build system provide a set of higher-level functions that can be used in build description files. Consider this example: add_program ('a', 'a.c') This is a function call that creates targets necessary to create executable file from source file a.c. Depending on configured properties, different commands line may be used. However, add_program is higher-level, but rather thin level All targets are created immediately when build description is parsed, which makes it impossible to perform multi-variant builds. Often, change in any build property requires complete reconfiguration of the build tree In order to support true multivariant builds, Boost.Build introduces the concept of metatarget--object that is created when build description is parsed and can be later called with specific build properties to generate actual targets Consider an example: exe a : a.cpp ; When this declaration is parsed, Boost.Build creates a metatarget, but does not yet decides what files must be created, or what commands must be used. After all build files are parsed, Boost.Build considers properties requested on the command line. Supposed you have invoked Boost.Build with: bjam toolset=gcc toolset=msvc In that case, the metatarget will be called twice, once with toolset=gcc and once with toolset=msvc. Both invocations will produce concrete targets, that will have different extensions and use different command lines. Another key concept is build property. Build property is a variable that affects the build process. It can be specified on the command line, and is passed when calling a metatarget While all build tools have a similar mechanism, Boost.Build differs by requiring that all build properties are declared in advance, and providing a large set of properties with portable semantics The final concept is property propagation. Boost.Build does not require that every metatarget is called with the same properties. Instead, the 'top-level' metatargets are called with the properties specified on the command line Each metatarget can elect to augment or override some properties (in particular, using the requirements mechanism, see the section called "Requirements": http://www.boost.org/boost- build2/doc/html/bbv2/overview/targets.html#bbv2.overview.targets.requirements) Then, the dependency metatargets are called with modified properties and produce concrete targets that are then used in build process Of course, dependency metatargets maybe in turn modify build properties and have dependencies of their own. For more in-depth treatment of the requirements and concepts, you may refer to SYRCoSE 2009 Boost.Build article (http://syrcose.ispras.ru/2009/files/04_paper.pdf). SEE ALSO
boost-libraries(3) SUPPORT
Please report any bugs to https://svn.boost.org/trac/boost/ COPYRIGHT
Boost Software License - Version 1.0 - August 17th, 2003 See the LICENSE_1_0.txt file for more information on that license, or directly on Internet: http://www.boost.org/LICENSE_1_0.txt Doxygen Sat Nov 19 2011 bjam(1)
Man Page