From d649f55b80cec124f64fb43ac0392140b918f1ff Mon Sep 17 00:00:00 2001 From: Vladimir Prus Date: Thu, 3 Jul 2003 09:13:05 +0000 Subject: [PATCH] Lots of documentation rearrangement and improvement. [SVN r18927] --- boost_build_v2.html | 932 +++++++++++++++++++++------------------ doc/architecture.html | 88 +++- doc/extending.html | 154 +++++++ doc/tools.html | 64 +-- v2/boost_build_v2.html | 932 +++++++++++++++++++++------------------ v2/doc/architecture.html | 88 +++- v2/doc/extending.html | 154 +++++++ v2/doc/tools.html | 64 +-- 8 files changed, 1542 insertions(+), 934 deletions(-) create mode 100644 doc/extending.html create mode 100644 v2/doc/extending.html diff --git a/boost_build_v2.html b/boost_build_v2.html index 1e3060aaf..75ecd7398 100644 --- a/boost_build_v2.html +++ b/boost_build_v2.html @@ -22,12 +22,12 @@ div.alert { color: red } table { align: center; border: thin; } - + + - build request, build request expansion and directly requested targets + - conditional properties + -->

-
-
Tutorial
+ + + -
-
-
Hello, world
+
+ -
Properties
+ + + + + +
This documentOther documents
+
+
Tutorial
-
Project hierarchy
+
+
+
Hello, world
-
Using libraries
+
Properties
-
Library dependencies
+
Project hierarchy
-
Static and shared libraries
+
Using libraries
-
Prebuilt targets
-
-
+
Library + dependencies
-
Reference documentation
+
Static and shared + libraries
-
-
-
Overview
+
Prebuilt targets
+
+
-
Builtin facilities
+
Reference documentation
-
-
-
Features
-
-
+
+
+
Overview
-
Features and properties
+
Main targets
-
-
-
Defintions
+
Projects
-
Property Validity
+
Target identifiers and + references
-
Feature Attributes
+
Builtin facilities
-
Feature Declaration
-
-
+
+
+
Main + targets
-
Build Variants
+
Features
+
+
+
+
-
Subfeatures
+
Detailed reference
-
Initialization
+
+
+
Features and + properties
-
Command line
+
+
+
Defintions
-
Projects
+
Property + Validity
-
Targets
+
Feature + Attributes
-
Build process
-
-
-
+
Feature + Declaration
+
+ + +
Build Variants
+ +
Subfeatures
+ +
Initialization
+ +
Command line
+ +
Build process
+ + + + 		+
+
Extender manual
+ +
Recipes
+ +
Architecture
+
+

Installation

@@ -138,12 +178,12 @@ bjam there. A simple application will be built. You can also play with other projects in examples-v2. + it somewhere. + +

It is slighly better way is to copy new/user-config.jam + into one of the locations where it can be found (given in this table). This prevent you from + accidentally overwriting your config when updating.

--> @@ -638,8 +678,407 @@ boost-build /path/to/boost.build ; date. At this step, implicit dependencies are also scanned and accounted for, as described here.

+

Main targets

+ +

Main target is a user-defined named entity + which can be build, for example a named executable file. Declaring a main + target is usually done using one of main + target rules. The user can also declare custom main target rules.

+ +

Most main targets rules in Boost.Build use similiar syntax:

+
+    rule-name main-target-name 
+        : sources 
+        : requirements 
+        : default-build 
+        : usage-requirements 
+        ;
+   
+
+ + + +

Some main target rules have shorter list of parameters, and you should + consult their documentation for details.

+ +

Building of the same main target can differ greatly from platform to + platform. For example, you might have different list of sources for + different compilers. Therefore it is possible to invoke main target rules + several times for a single main target. For example:

+
+    exe a : a_gcc.cpp : <toolset> ;
+    exe a : a.cpp ;
+
+ Each call to the 'exe' rule defines a new main target + alternative for the main target a. In this case, the first + alternative will be used for the gcc toolset, while the second + alternative will be used in other cases. TODO: document the exact + selection method under "Build process" below. + +

Sometime a main target is really needed only by some other main + target. E.g. a rule that declared test-suite uses a main target that + represent test, but those main targets are rarely needed by themself.

+ +

It possible to declare target inline, i.e. the "sources" parameter may + include call to other main rules. For example:

+
+    exe hello : hello.cpp 
+       [ obj helpers : helpers.cpp : <optimization>off ] ;
+   
+
+ Will cause "helpers.cpp" to be always compiled without optimization. It's + possible to request main targets declared inline, but since they are + considered local, they are renamed to + "parent-main-target_name..main-target-name". In the example above, to + build only helpers, one should run "bjam hello..helpers". + +

Projects

+ +

Boost.Build considers every software it build as organized into + projects — modules which declare targets. Projects are + organized in a hierarchical structure, so each project may have a single + parent project and a number of subprojects.

+ +

Most often, projects are created as result of loading Jamfile + — files which are specially meant to describe projects. Boost.Build + will implicitly load Jamfile in the invocation directory, and all + Jamfiles referred by the first one, creating the hierarchy of + projects.

+ +

The exact name of file that describes project is configurable. By + default, it's Jamfile, but can be changed by setting global + variables JAMFILE, for example in boost-build.jam file. + The value of the variable is a list of regex patterns that are used when + searching for Jamfile in a directory.

+ +

Every Boost.Build modules can decide to act as project and be able to + declare targets. For example, the site-config.jam module can + declare libraries available on a given host, as described here.

+ +

There are three things that can be put in Jamfile: declarations of + main targets, calls to a number of predefined rules, and arbitrary user + code. The predefined rules are listed below:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
RuleSemantic
projectDefine project attributes.
use-projectMake another project known.
build-projectBuild another project when this one is built.
explicitStates that the target should be built only by explicit + request.
+ +

Each project is also associated with project root. That's a + root for a tree of projects, which specifies some global properties.

+ +

Project root

+ Project root for a projects is the nearest parent directory which + contains a file called project-root.jam. That file defines + certain properties which apply to all projects under project root. It + can: + + + +

To facilitate declaration of simple projects, Jamfile and project-root + can be merged together. To achieve this effect, the project root file + should call the project rule. The semantic is precisely the same + as if the call was made in Jamfile, except that project-root.jam will + start serve as Jamfile. The Jamfile in the directory of project-root.jam + will be ignored, and project-root.jam will be able to declare main + targets as usual.

+ +

Project attributes

+ +

For each project, there are several attributes.

+ +

Project id is a short way to denote a project, as opposed to + the Jamfile's pathname. It is a hierarchical path, unrelated to + filesystem, such as "boost/thread". Target + references make use of project ids to specify a target.

+ +

Source location specifies the directory where sources for the + project are located.

+ +

Project requirements are requirements that apply to all the + targets in the projects as well as all subprojects.

+ +

Default build is the build request that should be used when + no build request is specified explicitly.

+ +

The default values for those attributes are given in + the table below. In order to affect them, Jamfile may call the + project rule. The rule has this syntax:

+
+    project id : <attributes> ;
+   
+
+ Here, attributes is a sequence of (attribute-name, attribute-value) + pairs. The list of attribute names along with its handling is also shown + in the table below. For example, it it possible to write: +
+    project tennis 
+        : requirements <threading>multi 
+        : default-build release
+        ;
+   
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AttributeName for the 'project' ruleDefault valueHandling by the 'project' rule
Project idnonenoneAssigned from the first parameter of the 'project' rule. It is + assumed to denote absolute project id.
Source locationsource-locationThe location of jamfile for the projectSets to the passed value
RequirementsrequirementsThe parent's requirementsThe parent's requirements are refined with the passed requirement + and the result is used as the project requirements.
Default builddefault-buildnoneSets to the passed value
Build directorybuild-dirIf parent has a build dir set, the value of it, joined with the + relative path from parent to the current project. Otherwise, + emptySets to the passed value, interpreted as relative to the + project's location.
+ +

Project relationship

+ +

There are three kinds of project relationships.

+ +

First is parent-child. This relationship is established implicitly: + parent directories of a project are searched, and the first found Jamfile + is assumed to define the parent project. The parent-child relationship + affects only attribute values for the child project.

+ +

Second is build relationship. Some project may + request to recursively build other projects. Those project need not be + child projects. The build-project rule is used for that:

+
+    build-project src ;   
+
+ +

The third kind is the 'use' relationship. In + means that one project uses targets from another. It is possible to just + refer to target in other projects using target id. However, if target id + uses project id, it is required that the project id is known. The + use-project rule is employed to guarantee that.

+
+    use-project ( id : location )
+   
+
+ It loads the project at the specified location, which makes its project + id available in the project which invokes the rule. It is required that + the id parameter passed to the use-project rule be + equal to the id that the loaded project declared. At this moment, the + id paremeter should be absolute project id. + +

Target identifiers and references

+ +

Target identifier is used to denote a target. There are two + syntaxes for it. First is the preferred one, described below. The second + is older syntax, which is retained to backward compatibility reasons, but + will be removed in a future release. It is not documented

+ +

The current syntax is

+
+    target-id -> (project-id | target-name | file-name )
+                  | (project-id | directory-name) "//" target-name   
+    project-id -> path
+    target-name -> path
+    file-name -> path
+    directory-name -> path                  
+
+ This grammar allows some elements to be recognized as either + + + To determine the real meaning a check is made if project-id by the + specified name exists, and then if main target of that name exists. For + example, valid target ids might be: +
+    a                                    -- target in current project
+    lib/b.cpp                            -- regular file
+    /boost/thread                        -- project "/boost/thread"
+    /home/ghost/build/lr_library//parser -- target in specific project
+
+ +

Rationale:Target is separated from project by special separator + (not just slash), because:

+ + + +

Target reference is used to specify a + source target, and may additionally specify desired properties for that + target. It has this syntax:

+
+    target-reference -> target-id [ "/" requested-properties ]
+    requested-properties -> property-path
+
+ For example, +
+    exe compiler : compiler.cpp libs/cmdline/<optimization>space ;
+
+ would cause the version of cmdline library, optimized for space, + to be linked in even if the compiler executable is build with + optimization for speed. +

Builtin facilities

+

Main targets

+ +
+
exe
+ +
Creates a regular executable file.
+ +
lib
+ +
Creates a library file. Depending on the value of <link> + feature the library will be either static or shared.
+ +
alias
+ +
Builds all the source targets and returns them unmodified. Please + run "bjam --help alias" for more details.
+ +
stage
+ +
Copies a number of targets to a single directory. The primary + purpose is installing binaries. Please run "bjam --help stage" for more + details.
+ +
unit-test (from module "testing")
+ +
Creates an executable file and runs it. Build won't succeed unless + the executable runs successfully. The rule is usefull for creating test + program which should be rerun whenever any dependency changes. + +
+
+

Features

@@ -675,6 +1114,8 @@ boost-build /path/to/boost.build ;
+

Detailed reference

+

Features and properties

Definitions

@@ -1159,391 +1600,6 @@ borland/runtime-link=static,dynamic -

Projects

- -

Boost.Build considers every software it build as organized into - projects — modules which declare targets. Projects are - organized in a hierarchical structure, so each project may have a single - parent project and a number of subprojects.

- -

Most often, projects are created as result of loading Jamfile - — files which are specially meant to describe projects. Boost.Build - will implicitly load Jamfile in the invocation directory, and all - Jamfiles referred by the first one, creating the hierarchy of - projects.

- -

The exact name of file that describes project is configurable. By - default, it's Jamfile, but can be changed by setting global - variables JAMFILE, for example in boost-build.jam file. - The value of the variable is a list of regex patterns that are used when - searching for Jamfile in a directory.

- -

Every Boost.Build modules can decide to act as project and be able to - declare targets. For example, the site-config.jam module can - declare libraries available on a given host, as described here.

- -

There are three things that can be put in Jamfile: declarations of - main targets, calls to a number of predefined rules, and arbitrary user - code. The predefined rules are listed below:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RuleSemantic
projectDefine project attributes.
use-projectMake another project known.
build-projectBuild another project when this one is built.
explicitStates that the target should be built only by explicit - request.
- -

Each project is also associated with project root. That's a - root for a tree of projects, which specifies some global properties.

- -

Project root

- Project root for a projects is the nearest parent directory which - contains a file called project-root.jam. That file defines - certain properties which apply to all projects under project root. It - can: - - - -

To facilitate declaration of simple projects, Jamfile and project-root - can be merged together. To achieve this effect, the project root file - should call the project rule. The semantic is precisely the same - as if the call was made in Jamfile, except that project-root.jam will - start serve as Jamfile. The Jamfile in the directory of project-root.jam - will be ignored, and project-root.jam will be able to declare main - targets as usual.

- -

Project attributes

- -

For each project, there are several attributes.

- -

Project id is a short way to denote a project, as opposed to - the Jamfile's pathname. It is a hierarchical path, unrelated to - filesystem, such as "boost/thread". Target - references make use of project ids to specify a target.

- -

Source location specifies the directory where sources for the - project are located.

- -

Project requirements are requirements that apply to all the - targets in the projects as well as all subprojects.

- -

Default build is the build request that should be used when - no build request is specified explicitly.

- -

The default values for those attributes are given in - the table below. In order to affect them, Jamfile may call the - project rule. The rule has this syntax:

-
-    project id : <attributes> ;
-   
-
- Here, attributes is a sequence of (attribute-name, attribute-value) - pairs. The list of attribute names along with its handling is also shown - in the table below. For example, it it possible to write: -
-    project tennis 
-        : requirements <threading>multi 
-        : default-build release
-        ;
-   
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
AttributeName for the 'project' ruleDefault valueHandling by the 'project' rule
Project idnonenoneAssigned from the first parameter of the 'project' rule. It is - assumed to denote absolute project id.
Source locationsource-locationThe location of jamfile for the projectSets to the passed value
RequirementsrequirementsThe parent's requirementsThe parent's requirements are refined with the passed requirement - and the result is used as the project requirements.
Default builddefault-buildnoneSets to the passed value
Build directorybuild-dirIf parent has a build dir set, the value of it, joined with the - relative path from parent to the current project. Otherwise, - emptySets to the passed value, interpreted as relative to the - project's location.
- -

Project relationship

- -

There are three kinds of project relationships.

- -

First is parent-child. This relationship is established implicitly: - parent directories of a project are searched, and the first found Jamfile - is assumed to define the parent project. The parent-child relationship - affects only attribute values for the child project.

- -

Second is build relationship. Some project may - request to recursively build other projects. Those project need not be - child projects. The build-project rule is used for that:

-
-    build-project src ;   
-
- -

The third kind is the 'use' relationship. In - means that one project uses targets from another. It is possible to just - refer to target in other projects using target id. However, if target id - uses project id, it is required that the project id is known. The - use-project rule is employed to guarantee that.

-
-    use-project ( id : location )
-   
-
- It loads the project at the specified location, which makes its project - id available in the project which invokes the rule. It is required that - the id parameter passed to the use-project rule be - equal to the id that the loaded project declared. At this moment, the - id paremeter should be absolute project id. - -

Targets

- -

There are two user-visible kinds of targets in Boost.Build. First are - "abstract" — they correspond to things declared by user, for - example, projects and executable files. The primary thing about abstract - target is that it's possible to request them to be build with a - particular values of some properties. Each combination of properties may - possible yield different set of real file, so abstract target do not have - a direct correspondence with files.

- -

File targets, on the contary, are associated with concrete files. - Dependency graphs for abstract targets with specific properties are - constructed from file targets. User has no was to create file targets, - however it can specify rules that detect file type for sources, and also - rules for transforming between file targets of different types. That - information is used in constructing dependency graph, as desribed in the - next section. Note:File targets are not - the same as targets in Jam sense; the latter are created from file - targets at the latest possible moment. Note:"File target" is a - proposed name for what we call virtual targets. It it more understandable - by users, but has one problem: virtual targets can potentially be - "phony", and not correspond to any file.

- -

Main targets and main target alternatives

- -

Main target is a named entity which can be - build, for example a named executable file. To declare a main target, - user invokes some of the main target - rules, passing it things like list of sources and requirements.

- -

It is possible to have different list of sources for different - toolsets, therefore it is possible to invoke main target rules several - times for a single main target. For example:

-
-    exe a : a_gcc.cpp : <toolset> ;
-    exe a : a.cpp ;
-
- Each call to the 'exe' rule defines a new main target - alternative for the main target a.exe. In this case, the - first alternative will be used for the gcc toolset, while the - second alternative will be used in other cases. TODO: document the exact - selection method under "Build process" below. - -

Target identifiers and references

- -

Target identifier is used to denote a target. There are two - syntaxes for it. First is the preferred one, described below. The second - is older syntax, which is retained to backward compatibility reasons, but - will be removed in a future release. It is not documented

- -

The current syntax is

-
-    target-id -> (project-id | target-name | file-name )
-                  | (project-id | directory-name) "//" target-name   
-    project-id -> path
-    target-name -> path
-    file-name -> path
-    directory-name -> path                  
-
- This grammar allows some elements to be recognized as either - - - To determine the real meaning a check is made if project-id by the - specified name exists, and then if main target of that name exists. For - example, valid target ids might be: -
-    a                                    -- target in current project
-    lib/b.cpp                            -- regular file
-    /boost/thread                        -- project "/boost/thread"
-    /home/ghost/build/lr_library//parser -- target in specific project
-
- -

Rationale:Target is separated from project by special separator - (not just slash), because:

- - - -

Target reference is used to specify a - source target, and may additionally specify desired properties for that - target. It has this syntax:

-
-    target-reference -> target-id [ "/" requested-properties ]
-    requested-properties -> property-path
-
- For example, -
-    exe compiler : compiler.cpp libs/cmdline/<optimization>space ;
-
- would cause the version of cmdline library, optimized for space, - to be linked in even if the compiler executable is build with - optimization for speed. - -

File targets

- As described above, file targets corresponds to files that Boost.Build - manages. User's may be concerned about file targets in three ways: when - declaring file target types, when declaring transformations between - types, and when determining where file target will be placed. File - targets can also be connected with actions, that determine how the target - is created. Both file targets and actions are implemented in the - virtual-target module. - -
Types
- A file target can be given a file, which determines what transformations - can be applied to the file. The type.register rule declares new - types. File type can also be assigned a scanner, which is used to find - implicit dependencies. See dependency - scanning below. - -

Target paths

- -

To distinguish targets build with different properties, they are put - in different directories. Rules for determining target paths are given - below:

- -
    -
  1. All targets are placed under directory corresponding to the project - where they are defined.
    2. - -
  2. Each non free, non incidental property cause an additional element - to be added to the target path. That element has the form - <feature-name>-<feature-value> for ordinary - features and <feature-value> for implicit ones. [Note - about composite features].
    3. - -
  3. If the set of free, non incidental properties is different from the - set of free, non incidental properties for the project in which the - main target that uses the target is defined, a part of the form - main_target-<name> is added to the target path. - Note:It would be nice to completely track free features also, - but this appears to be complex and not extremely needed.
    4. -
- -

For example, we might have these paths:

-
-    debug/optimization-off
-    debug/main-target-a
-   
-
-

Build request

Build process

@@ -1728,7 +1784,7 @@ borland/runtime-link=static,dynamic retrieved and cloned, with appropriate change in names.
-

Last modified: June 16, 2003

+

Last modified: Jule 3, 2003

© Copyright Vladimir Prus 2002-2003. Permission to copy, use, modify, sell and distribute this document is granted provided this diff --git a/doc/architecture.html b/doc/architecture.html index 4a32a6f66..bf00cae21 100644 --- a/doc/architecture.html +++ b/doc/architecture.html @@ -21,12 +21,12 @@ br.clear { clear: left } div.alert { color: red } table { align: center; border: thin; } - + + - build request, build request expansion and directly requested targets + - conditional properties + -->

+
+

This document is work-in progress. Don't expect much from it + yet.

+
+
Dependency scanning
+

Targets

+ +

There are two user-visible kinds of targets in Boost.Build. First are + "abstract" — they correspond to things declared by user, for + example, projects and executable files. The primary thing about abstract + target is that it's possible to request them to be build with a + particular values of some properties. Each combination of properties may + possible yield different set of real file, so abstract target do not have + a direct correspondence with files.

+ +

File targets, on the contary, are associated with concrete files. + Dependency graphs for abstract targets with specific properties are + constructed from file targets. User has no was to create file targets, + however it can specify rules that detect file type for sources, and also + rules for transforming between file targets of different types. That + information is used in constructing dependency graph, as desribed in the + next section. Note:File targets are not + the same as targets in Jam sense; the latter are created from file + targets at the latest possible moment. Note:"File target" is a + proposed name for what we call virtual targets. It it more understandable + by users, but has one problem: virtual targets can potentially be + "phony", and not correspond to any file.

+

Dependency scanning

Dependency scanning is the process of finding implicit dependencies @@ -208,6 +236,58 @@ bound via LOCATE_TARGET to "build" and we'll call INCLUDE on that found target, instread of creating a completely unrelated one. + +

+ The remainder of this document is not indended to be read at all. This + will be rearranged in future. +
+ +

File targets

+ As described above, file targets corresponds to files that Boost.Build + manages. User's may be concerned about file targets in three ways: when + declaring file target types, when declaring transformations between + types, and when determining where file target will be placed. File + targets can also be connected with actions, that determine how the target + is created. Both file targets and actions are implemented in the + virtual-target module. + +
Types
+ A file target can be given a file, which determines what transformations + can be applied to the file. The type.register rule declares new + types. File type can also be assigned a scanner, which is used to find + implicit dependencies. See dependency + scanning below. + +

Target paths

+ +

To distinguish targets build with different properties, they are put + in different directories. Rules for determining target paths are given + below:

+ +
    +
  1. All targets are placed under directory corresponding to the project + where they are defined.
    2. + +
  2. Each non free, non incidental property cause an additional element + to be added to the target path. That element has the form + <feature-name>-<feature-value> for ordinary + features and <feature-value> for implicit ones. [Note + about composite features].
    3. + +
  3. If the set of free, non incidental properties is different from the + set of free, non incidental properties for the project in which the + main target that uses the target is defined, a part of the form + main_target-<name> is added to the target path. + Note:It would be nice to completely track free features also, + but this appears to be complex and not extremely needed.
    4. +
+ +

For example, we might have these paths:

+
+    debug/optimization-off
+    debug/main-target-a
+   
+

Last modified: June 30, 2003

diff --git a/doc/extending.html b/doc/extending.html new file mode 100644 index 000000000..84749a524 --- /dev/null +++ b/doc/extending.html @@ -0,0 +1,154 @@ + + + + + + + + + + Boost.Build v2 extender manual + + + + + + +

+ +

Boost.Build v2 extender manual
+

+
+ +
+
Introduction
+ +
Target types
+ +
Tools
+ +
Main target rules
+ +
Scanners
+
+
+ +

Introduction

+ +

This document explains how to extend Boost.Build to accomodate your + local requirements. Let's start with quite simple, but realistic + example.

+ +

Say you're writing an application which generates C++ code. If you + ever did this, you know that it's not nice. Embedding large portions of + C++ code in string literals is very awkward. A much better solution + is:

+ +
    +
  1. Write the template of the code to be generated, leaving + placeholders at the points which will change
    2. + +
  2. Access the template in your application and replace placeholders + with appropriate text.
    3. + +
  3. Write the result.
    4. +
+ +

It's quite easy to archive. You write special verbatim files, which + are just C++, except that the very first line of the file gives a name of + variable that should be generated. A simple tool is created which takes + verbatim file and creates a cpp file with a single char* variable, which + name is taken from the first line of verbatim file, and which value is + properly quoted content of the verbatim file.

+ +

Let's see what Boost.Build can do.

+ +

First off, Boost.Build has no idea about "verbatim files". So, you + must register a new type. The following code does it:

+
+    import type ;
+    type.register VERBATIM : verbatim ;
+   
+
+ +

The first parameter to 'type.register' gives the name of declared + type. By convention, it's uppercase. The second parameter is suffix for + this type. So, if Boost.Build sees "code.verbatim" in the list of + sources, it knows that it's of type VERBATIM.

+ +

Lastly, you need to tool to convert verbatim files to C++. Say you've + stetched such a tool in Python. Then, you have to inform Boost.Build + about the tool. The Boost.Build concept which represent tool is + generator.

+ +

First, you say that generator 'inline-file' is able to convert + VERBATIM type into C++:

+
+    import generators ;
+    generators.register-standard verbatim.inline-file : VERBATIM : CPP ;
+   
+
+ +

Second, you must specify the commands to be run to actually perform + convertion:

+
+    actions inline-file
+    {
+        ./inline-file.py $(<) $(>)
+    }
+   
+
+ + +

Now, we're ready to tie it all together. Put all the code above in + file "verbatim.jam", add "import verbatim ;" to "project-root.jam", and + it's possible to write the following in Jamfile:

+
+    exe codegen : codegen.cpp class_template.verbatim usage.verbatim ;
+   
+
+ The verbatim files will be automatically converted into C++ and linked + it. + +

The complete code is available in examples-v2/customization + directory.

+ +

Target types

+ +

Tools

+ +

Main target rules

+ +

Scanners

+
+ +

Last modified: Jule 3, 2003

+ +

© Copyright Vladimir Prus 2002-2003. Permission to copy, use, + modify, sell and distribute this document is granted provided this + copyright notice appears in all copies. This document is provided ``as + is'' without express or implied warranty, and with no claim as to its + suitability for any purpose.

+ + + + diff --git a/doc/tools.html b/doc/tools.html index 907abe68b..a24a601c0 100644 --- a/doc/tools.html +++ b/doc/tools.html @@ -3,7 +3,7 @@ + "HTML Tidy for Linux/x86 (vers 1st April 2002), see www.w3.org"> @@ -14,52 +14,66 @@ c++boost.gif (8819 bytes) - - SourceForge.net Logo + width="277" height="86"> SourceForge.net Logo

Boost Build System V2 — supported tools

Compilers

-

The following compilers pass Boost.Build tests: -