boost/build
2
0
Fork 0
mirror of https://github.com/boostorg/build.git synced 2026-02-18 01:52:17 +00:00
Code Issues Projects Releases Wiki Activity

Merge from HEAD

Browse Source 
[SVN r36605]
This commit is contained in:
Vladimir Prus
2007-01-06 12:39:42 +00:00
parent df3a0ee29e
commit 1ace4d3801
12 changed files with 629 additions and 462 deletions
Download Patch File Download Diff File Expand all files Collapse all files

56
v2/build/generators.jam
View File

@@ -371,7 +371,37 @@ class generator
}
}
return $(result) ;
}
}
# Determine the name of the produced target from the
# names of the sources.
rule determine-output-name ( sources + )
{
# The simple case if when a name
# of source has single dot. Then, we take the part before
# dot. Several dots can be caused by:
# - Using source file like a.host.cpp
# - A type which suffix has a dot. Say, we can
# type 'host_cpp' with extension 'host.cpp'.
# In the first case, we want to take the part till the last
# dot. In the second case -- no sure, but for now take
# the part till the last dot too.
name = [ utility.basename [ $(sources[1]).name ] ] ;
for local s in $(sources[2])
{
local n2 = [ utility.basename [ $(s).name ] ] ;
if $(n2) != $(name)
{
error "$(self.id): source targets have different names: cannot determine target name" ;
}
}
# Names of sources might include directory. We should strip it.
name = $(name:D=) ;
return $(name) ;
}
# Constructs targets that are created after consuming 'sources'.
# The result will be the list of virtual-target, which the same length
@@ -397,29 +427,7 @@ class generator
{
if ! $(name)
{
# Determine the name of the produced target from the
# names of the sources. The simple case if when a name
# of source has single dot. Then, we take the part before
# dot. Several dots can be caused by:
# - Using source file like a.host.cpp
# - A type which suffix has a dot. Say, we can
# type 'host_cpp' with extension 'host.cpp'.
# In the first case, we want to take the part till the last
# dot. In the second case -- no sure, but for now take
# the part till the last dot too.
name = [ utility.basename [ $(sources[1]).name ] ] ;
for local s in $(sources[2])
{
local n2 = [ utility.basename [ $(s).name ] ] ;
if $(n2) != $(name)
{
error "$(self.id): source targets have different names: cannot determine target name" ;
}
}
# Names of sources might include directory. We should strip it.
name = $(name:D=) ;
name = [ determine-output-name $(sources) ] ;
}
# Assign an action for each target

19
v2/build/targets.jam
View File

@@ -1181,10 +1181,12 @@ class basic-target : abstract-target
{
if [ modules.peek : .debug-building ]
{
ECHO [ targets.indent ] "Building target '$(self.name)'" ;
ECHO ;
local fn = [ full-name ] ;
ECHO [ targets.indent ] "Building target '$(fn)'" ;
targets.increase-indent ;
ECHO [ targets.indent ] "Build request: " [ $(property-set).raw ] ;
ECHO [ targets.indent ] "Target requirements: " [ $(self.requirements).raw ] ;
targets.increase-indent ;
}
if ! $(self.generated.$(property-set))
@@ -1194,7 +1196,8 @@ class basic-target : abstract-target
if [ modules.peek : .debug-building ]
{
ECHO [ targets.indent ] "Common properties are" [ $(rproperties).raw ] ;
ECHO ;
ECHO [ targets.indent ] "Common properties:" [ $(rproperties).raw ] ;
}
if $(rproperties[1]) != "@error" && [ $(rproperties).get <build> ] != no
@@ -1212,6 +1215,7 @@ class basic-target : abstract-target
if [ modules.peek : .debug-building ]
{
ECHO ;
ECHO [ targets.indent ]
"Usage requirements for $(self.name) are " $(usage-requirements) ;
}
@@ -1220,6 +1224,12 @@ class basic-target : abstract-target
$(usage-requirements) ] ;
usage-requirements = [ property-set.create $(usage-requirements) ] ;
if [ modules.peek : .debug-building ]
{
ECHO [ targets.indent ]
"Build properties: " [ $(rproperties).raw ] ;
}
local extra = [ $(rproperties).get <source> ] ;
source-targets += $(extra:G=) ;
# We might get duplicate sources, for example if
@@ -1272,8 +1282,7 @@ class basic-target : abstract-target
ECHO [ targets.indent ] "Already built" ;
}
}
targets.decrease-indent ;
return $(self.generated.$(property-set)) ;
}

8
v2/changes.txt
View File

@@ -16,8 +16,12 @@ Changes in this release:
- New 'project.extension' rule for declaring standalone
projects.
- New 'conditional' convenience rule.
- New 'path.glob-tree' rule.
- New 'glob-tree' rule.
- The 'glob' rule accepts patterns to exclude.
- Inline targets are now marked explicit automatically.
- Toolsets can now implicitly add requirements to
all targets.
- New 'generate' rule.
Documentation changes:
@@ -32,7 +36,7 @@ The following bugs were fixed:
mkdir commands.
- Numerious fixes in Boost autolink support
- Numerious fixes in Boost.Python support.
- Indirect properties not evaluates in usage requirements.
Milestone 11 (Jule 20, 2006)

37
v2/doc/src/advanced.xml
View File

@@ -49,24 +49,16 @@
How to configure Boost.Build</link></para>
</listitem>
<listitem>
<para><link linkend="bbv2.advanced.jamfiles">
How to write Jamfiles</link></para>
<para><link linkend="bbv2.advanced.targets">
How to write declares targets in Jamfiles</link></para>
</listitem>
<listitem>
<para><link linkend="bbv2.advanced.build_process">
How the build process works</link></para>
</listitem>
<listitem>
<para>Some Basics about the Boost.Jam language. See also the
<ulink
url="http://www.boost.org/tools/jam/index.html">Boost.Jam</ulink>
documentation.
<!-- Something better than this is desperately needed; the
tutorial at least should clarify that whitespace is
significant and we shouldn't get any further than the
beginning of this document before briefly explaining
Jam's data and procedural model, rule
signatures, and Boost.Build modules -->
<para>Some Basics about the Boost.Jam language. See
<xref linkend="bbv2.advanced.jam_language"/>.
</para>
</listitem>
</itemizedlist>
@@ -77,8 +69,7 @@
<para>This section will describe the basics of the Boost.Jam
language&#x2014;just enough for writing Jamfiles. For more information,
please see the <ulink
url="http://www.boost.org/tools/jam/index.html">Boost.Jam</ulink>
please see the <link linkend="bbv2.jam">Boost.Jam</link>
documentation.</para>
<para>Boost.Jam has an interpreted, procedural language.
@@ -543,7 +534,7 @@ bjam optimization=space
entity that can be built, for example an executable file.
Declaring a main target is usually done using one of the main
target rules described in <xref linkend=
"bbv2.reference.target-rules"/>. The user can also declare
"bbv2.reference.rules"/>. The user can also declare
custom main target rules as shown in <xref
linkend="bbv2.extending.rules"/>.
</para>
@@ -1011,17 +1002,9 @@ project tennis
</para>
<para>Besides defining projects and main targets, Jamfiles
commonly invoke utility rules such as
<functionname>constant</functionname> and
<functionname>path-constant</functionname>, which inject a
specified Boost.Jam variable setting into this project's Jamfile
module and those of all its subprojects. See <xref
linkend="bbv2.advanced.other-rules"/> for a complete description
of these utility rules. Jamfiles are regular Boost.Jam source
files and Boost.Build modules, so naturally they can contain any kind of Boost.Jam code,
including rule definitions.
<!-- I improved that sentence, but I don't think it belongs
here. I suggest you strike it. -->
often invoke various utility rules. For the full list of rules
that can be directly used in Jamfile see
<xref linkend="bbv2.reference.rules"/>.
</para>
<para>Each subproject inherits attributes, constants and rules
@@ -1095,7 +1078,7 @@ project tennis
</para>
</tip>
<section>
<section id="bbv2.advanced.build_request">
<title>Build Request</title>
<para>

430
v2/doc/src/reference.xml
View File

@@ -153,7 +153,7 @@ boost-build build-system ;
An argument containing either slashes or
the <code>=</code> symbol specifies a number of build
request elements (see <xref
linkend="bbv2.reference.buildreq"/>). In its simplest
linkend="bbv2.advanced.build_request"/>). In its simplest
form, it's just a set of properties, separated by
slashes, which become a single build request element,
for example:
@@ -234,11 +234,12 @@ target1 debug gcc/runtime-link=dynamic,static
</section>
<section id="bbv2.reference.target-rules">
<title>Builtin targets</title>
<section id="bbv2.reference.rules">
<title>Builtin rules</title>
<para>This section contains the list of all target types defined
in Boost.Build.</para>
<para>This section contains the list of all rules that
can be used in Jamfile&#x2014;both rules that define new
targets and auxiliary rules.</para>
<variablelist>
<varlistentry>
@@ -283,23 +284,6 @@ target1 debug gcc/runtime-link=dynamic,static
file must be compiled with special properties.</para></listitem>
</varlistentry>
</variablelist>
</section>
<section id="bbv2.advanced.other-rules">
<title>Utility Rules</title>
<para>The following table describes utility rules that can be
used in Jamfiles. Detailed information for any of these rules can
be obtained by running:
<screen>
bjam --help project.<replaceable>rulename</replaceable>
</screen>
</para>
<variablelist>
<varlistentry>
<term><literal>glob</literal></term>
@@ -313,84 +297,348 @@ lib tools : [ glob *.cpp ] ;
</varlistentry>
<varlistentry>
<term><literal>lib</literal></term>
<term><literal>project</literal></term>
<listitem><para>Creates an library file. See
<xref linkend="bbv2.tasks.libraries"/>.</para></listitem>
<listitem><para>Declares project id and attributes, including
project requirements. See <xref linkend="bbv2.advanced.projects"/>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>use-project</literal></term>
<listitem><para>Assigns a symbolic project ID to a project at
a given path. This rule must be better documented!
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>explicit</literal></term>
<listitem><para>The <literal>explicit</literal> rule takes a single
parameter&#x2014;a list of target names. The named targets will
be marked explicit, and will be built only if they are explicitly
requested on the command line, or if their dependents are built.
Compare this to ordinary targets, that are built implicitly when
their containing project is built.</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>constant</literal></term>
<listitem><para>Sets project-wide constant. Takes two
parameters: variable name and a value and makes the specified
variable name accessible in this Jamfile and any child Jamfiles.
For example:
<programlisting>
constant VERSION : 1.34.0 ;
</programlisting>
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>path-constant</literal></term>
<listitem><para>Same as <literal>constant</literal> except that
the value is treated as path relative to Jamfile location. For example,
if <command>bjam</command> is invoked in the current directory,
and Jamfile in <filename>helper</filename> subdirectory has:
<programlisting>
path-constant DATA : data/a.txt ;
</programlisting>
then the variable <varname>DATA</varname> will be set to
<literal>helper/data/a.txt</literal>, and if <command>bjam</command>
is invoked from the <filename>helper</filename> directory, then
the variable <varname>DATA</varname> will be set to
<literal>data/a.txt</literal>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>build-project</literal></term>
<listitem><para>Cause some other project to be built. This rule
takes a single parameter&#x2014;a directory name relative to
the containing Jamfile. When the containing Jamfile is built,
the project located at that directory will be built as well.
At the moment, the parameter to this rule should be a directory
name. Project ID or general target references are not allowed.
</para></listitem>
</varlistentry>
</variablelist>
<table>
<title/>
<tgroup cols="2">
<thead>
<row>
<entry>Rule</entry>
<entry>Semantics</entry>
</row>
</thead>
</section>
<section id="bbv2.advanced.builtins.features">
<title>Builtin features</title>
<variablelist>
<varlistentry><term><literal>variant</literal></term>
<listitem>
<para>
A feature that combines several low-level features, making
it easy to request common build configurations.
</para>
<tbody>
<row>
<entry><link linkend=
"bbv2.advanced.projects.attributes.projectrule">project</link>
</entry>
<entry>Define this project's symbolic ID or attributes.</entry>
</row>
<row>
<entry><xref linkend=
"bbv2.advanced.projects.relationships.useprojectrule">use-project</xref></entry>
<entry>Make another project known so that it can be referred to by symbolic ID.</entry>
</row>
<row>
<entry><xref linkend=
"bbv2.advanced.projects.relationships.buildprojectrule">build-project</xref></entry>
<entry>Cause another project to be built when this one is built.</entry>
</row>
<row>
<entry><xref linkend=
"bbv2.reference.buildprocess.explict">explicit</xref></entry>
<entry>State that a target should be built only by explicit
request.</entry>
</row>
<row>
<entry>glob</entry>
<entry>Translate a list of shell-style wildcards into a
corresponding list of files.</entry>
</row>
<para><emphasis role="bold">Allowed values:</emphasis> <literal>debug</literal>, <literal>release</literal>,
<literal>profile</literal>.</para>
<para>The value <literal>debug</literal> expands to</para>
<programlisting>
&lt;optimization&gt;off &lt;debug-symbols&gt;on &lt;inlining&gt;off &lt;runtime-debugging&gt;on
</programlisting>
<para>The value <literal>release</literal> expands to</para>
<programlisting>
&lt;optimization&gt;speed &lt;debug-symbols&gt;off &lt;inlining&gt;full &lt;runtime-debugging&gt;off
</programlisting>
<para>The value <literal>profile</literal> expands to the same as
<literal>release</literal>, plus:</para>
<programlisting>
&lt;profiling&gt;on &lt;debug-symbols&gt;on
</programlisting>
<row>
<entry>constant</entry>
<entry>Injects a variable setting into this project's
Jamfile module and those of all its subprojects.</entry>
</row>
<para>User can define his own build variants using the <code>variant</code> rule from the <code>common</code>
module.</para>
<para><emphasis role="bold">Notee:</emphasis> Runtime
debugging is on in debug builds to suit the expectations of
people used to various IDEs.
<!-- Define "runtime debugging." Why will those people expect it to be on in debug builds? -->
</para>
</listitem></varlistentry>
<varlistentry id="bbv2.advanced.builtins.features.link">
<term><literal>link</literal></term>
<listitem>
<simpara>
A feature that controls how libraries are built.
</simpara>
<para><emphasis role="bold">Allowed values:</emphasis> <literal>shared</literal>,
<literal>static</literal></para>
</listitem></varlistentry>
<varlistentry><term><literal>source</literal></term>
<listitem>
<simpara>
The <code>&lt;source&gt;X</code> feature has the same effect on
building a target as putting X in the list of sources.
It's useful when you want to add
the same source to all targets in the project
(you can put &lt;source&gt; in requirements) or to conditionally
include a source (using conditional requirements, see <xref linkend="bbv2.tutorial.conditions"/>)
See also the <code>&lt;library&gt;</code> feature.
</simpara>
</listitem>
</varlistentry>
<varlistentry><term><literal>library</literal></term>
<listitem>
<simpara>
This feature is almost equivalent to the <code>&lt;source&gt;</code> feature,
except that it takes effect only for linking. When you want to
link all targets in a Jamfile to certain library, the
<code>&lt;library&gt;</code> feature is preferred over
<code>&lt;source&gt;X</code> -- the latter will add the library to
all targets, even those that have nothing to do with libraries.
</simpara>
</listitem>
</varlistentry>
<row>
<entry>path-constant</entry>
<entry>Injects a variable set to a path value into
this project's Jamfile module and those of all its subprojects.
If the value is a relative path it will be adjusted for
each subproject so that it refers to the same
directory.</entry>
</row>
<varlistentry><term><anchor id="bbv2.builtin.features.dependency"/>
<literal>dependency</literal></term>
<listitem>
<simpara>
Introduces a dependency on the target named by the
value of this feature (so it will be brought
up-to-date whenever the target being declared is).
The dependency is not used in any other way. For example, in
application with plugins, the plugins are not used when linking
the application,
application might have dependency on its plugins, even though
</tbody>
</tgroup>
</table>
</section>
, and
adds its usage requirements to the build properties
of the target being declared.
The primary use case is when you want
the usage requirements (such as <code>#include</code> paths) of some
library to be applied, but don't want to link to it.
<!-- It's hard to picture why anyone would want to do
that. Please flesh out this motivation -->
</simpara>
</listitem>
</varlistentry>
<varlistentry><term><anchor id="bbv2.builtin.features.use"/>
<literal>use</literal></term>
<listitem>
<simpara>
Introduces a dependency on the target named by the
value of this feature (so it will be brought
up-to-date whenever the target being declared is), and
adds its usage requirements to the build properties
<!-- Do you really mean "to the requirements?" -->
of the target being declared. The dependency is not used
in any other way. The primary use case is when you want
the usage requirements (such as <code>#include</code> paths) of some
library to be applied, but don't want to link to it.
<!-- It's hard to picture why anyone would want to do
that. Please flesh out this motivation -->
</simpara>
</listitem>
</varlistentry>
<varlistentry><term><anchor id="bbv2.reference.features.dll-path"/>
<literal>dll-path</literal></term>
<listitem>
<simpara>
Specify an additional directory where the system should
look for shared libraries when the executable or shared
library is run. This feature only affects Unix
compilers. Plase see <xref linkend="bbv2.faq.dll-path"/>
in <xref linkend="bbv2.faq"/> for details.
</simpara>
</listitem></varlistentry>
<varlistentry><term><literal>hardcode-dll-paths</literal></term>
<listitem>
<simpara>
Controls automatic generation of dll-path properties.
</simpara>
<para><emphasis role="bold">Allowed values:</emphasis>
<literal>true</literal>, <literal>false</literal>. This property
is specific to Unix systems. If an executable is built with
<code>&lt;hardcode-dll-paths&gt;true</code>, the generated binary
will contain the list of all the paths to the used shared
libraries. As the result, the executable can be run without
changing system paths to shared libraries or installing the
libraries to system paths. This
<!-- you need an antecedent. This _what_? -->
is very convenient during
development. Plase see the <link
linkend="bbv2.faq.dll-path">FAQ entry</link> for details.
Note that on Mac OSX, the paths are unconditionally hardcoded by
the linker, and it's not possible to disable that behaviour.
</para>
</listitem></varlistentry>
<varlistentry>
<term><literal>cflags</literal></term>
<term><literal>cxxflags</literal></term>
<term><literal>linkflags</literal></term>
<listitem>
<simpara>
The value of those features is passed without modification to the
corresponding tools. For <code>cflags</code> that's both the C and C++
compilers, for <code>cxxflags</code> that's the C++ compiler and for
<code>linkflags</code> that's the linker. The features are handy when
you're trying to do something special that cannot be achieved by
higher-level feature in Boost.Build.
</simpara>
</listitem>
</varlistentry>
<varlistentry><term><literal>warnings</literal></term>
<listitem>
<simpara>
The <code>&lt;warnings&gt;</code> feature controls the warning level of compilers. It has the following values:
<itemizedlist>
<listitem><para><code>off</code> - disables all warnings.</para></listitem>
<listitem><para><code>on</code> - enables default warning level for the tool.</para></listitem>
<listitem><para><code>all</code> - enables all warnings.</para></listitem>
</itemizedlist>
Default value is <code>all</code>.
</simpara>
</listitem>
</varlistentry>
<varlistentry><term><literal>warnings-as-errors</literal></term>
<listitem>
<simpara>
The <code>&lt;warnings-as-errors&gt;</code> makes it possible to treat warnings as errors and abort
compilation on a warning. The value <code>on</code> enables this behaviour. The default value is
<code>off</code>.
</simpara>
</listitem>
</varlistentry>
<varlistentry><term><literal>build</literal></term>
<listitem>
<para><emphasis role="bold">Allowed values:</emphasis> <literal>no</literal></para>
<para>
The <code>build</code> feature is used to conditionally disable build of a target. If <code>&lt;build&gt;no</code>
is in properties when building a target, build of that target is skipped. Combined with conditional requirements this
allows to skip building some target in configurations where the build is known to fail.
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>tag</literal></term>
<listitem><para>The <literal>tag</literal> feature is used to customize
the name of the generated files. The value should have the form:
<programlisting>@<replaceable>rulename</replaceable></programlisting> where
<replaceable>rulename</replaceable> should be a name of a rule with
the following signature:
<programlisting>rule tag ( name : type ? : property-set )</programlisting>
The rule will be called for each target with the default name computed
by Boost.Build, the type of the target, and property set. The rule
can either return a string that must be used as the name of the
target, or empty string, in which case the default name will be used.
</para>
<para>Most typical use of the <literal>tag</literal> feature is
to encode build properties, or library version in library target names.
You should take care to return non-empty string from the tag rule
only for types you care about &#x2014; otherwise, you might
end up modifying names of object files, generated header file and
other targets for which changing names does not make sense.</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>debug-symbols</literal></term>
<listitem>
<para><emphasis role="bold">Allowed values:</emphasis> <literal>on</literal>, <literal>off</literal>.</para>
<para>The <literal>debug-symbols</literal> feature specifies if
produced object files, executables and libraries should include
debug information.
Typically, the value of this feature is implicitly set by the
<literal>variant</literal> feature, but it can be explicitly
specified by the user. The most common usage is to build
release variant with debugging information.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section id="bbv2.reference.tools">
<title>Builtin tools</title>

277
v2/doc/src/tasks.xml
View File

@@ -43,8 +43,7 @@ exe hello : hello.cpp some_library.lib /some_project//library
<literal>PATH</literal> environment variable should include the path
to the libraries. It means you have to either add the paths
manually, or place the application and the libraries to the same
directory, for example using the <link linkend="bbv2.builtins.stage">
stage</link> rule.
directory. See <xref linkend="bbv2.tasks.installing"/>.
</para>
<!-- We should be emphasizing the use of the built-in testing
rules rather than continually discussing these quirks of
@@ -323,7 +322,7 @@ install headers
<bridgehead>Installing into Several Directories</bridgehead>
<para>The <link linkend="bbv2.builtins.alias"><code>alias</code></link>
<para>The <link linkend="bbv2.tasks.alias"><code>alias</code></link>
rule can be used when targets must be installed into several
directories:
<programlisting>
@@ -340,7 +339,7 @@ install install-lib : helper : /usr/lib ;
The only two which matter are
<link linkend="bbv2.builtin.features.dependency">
<varname>dependency</varname></link> and, on Unix,
<link linkend="bbv2.builtin.feature.dll-path"><varname>dll-path</varname></link>.
<link linkend="bbv2.reference.features.dll-path"><varname>dll-path</varname></link>.
</para>
<note>
@@ -553,277 +552,7 @@ exe app : app.cpp : &lt;implicit-dependency&gt;parser ;
targets from "parser" as potential dependencies.
</para>
</section>
<section id="bbv2.advanced.builtins.features">
<title>Builtin features</title>
<variablelist>
<varlistentry><term><literal>variant</literal></term>
<listitem>
<para>
A feature that combines several low-level features, making
it easy to request common build configurations.
</para>
<para><emphasis role="bold">Allowed values:</emphasis> <literal>debug</literal>, <literal>release</literal>,
<literal>profile</literal>.</para>
<para>The value <literal>debug</literal> expands to</para>
<programlisting>
&lt;optimization&gt;off &lt;debug-symbols&gt;on &lt;inlining&gt;off &lt;runtime-debugging&gt;on
</programlisting>
<para>The value <literal>release</literal> expands to</para>
<programlisting>
&lt;optimization&gt;speed &lt;debug-symbols&gt;off &lt;inlining&gt;full &lt;runtime-debugging&gt;off
</programlisting>
<para>The value <literal>profile</literal> expands to the same as
<literal>release</literal>, plus:</para>
<programlisting>
&lt;profiling&gt;on &lt;debug-symbols&gt;on
</programlisting>
<para>User can define his own build variants using the <code>variant</code> rule from the <code>common</code>
module.</para>
<para><emphasis role="bold">Notee:</emphasis> Runtime
debugging is on in debug builds to suit the expectations of
people used to various IDEs.
<!-- Define "runtime debugging." Why will those people expect it to be on in debug builds? -->
</para>
</listitem></varlistentry>
<varlistentry id="bbv2.advanced.builtins.features.link">
<term><literal>link</literal></term>
<listitem>
<simpara>
A feature that controls how libraries are built.
</simpara>
<para><emphasis role="bold">Allowed values:</emphasis> <literal>shared</literal>,
<literal>static</literal></para>
</listitem></varlistentry>
<varlistentry><term><literal>source</literal></term>
<listitem>
<simpara>
The <code>&lt;source&gt;X</code> feature has the same effect on
building a target as putting X in the list of sources.
It's useful when you want to add
the same source to all targets in the project
(you can put &lt;source&gt; in requirements) or to conditionally
include a source (using conditional requirements, see <xref linkend="bbv2.tutorial.conditions"/>)
See also the <code>&lt;library&gt;</code> feature.
</simpara>
</listitem>
</varlistentry>
<varlistentry><term><literal>library</literal></term>
<listitem>
<simpara>
This feature is almost equivalent to the <code>&lt;source&gt;</code> feature,
except that it takes effect only for linking. When you want to
link all targets in a Jamfile to certain library, the
<code>&lt;library&gt;</code> feature is preferred over
<code>&lt;source&gt;X</code> -- the latter will add the library to
all targets, even those that have nothing to do with libraries.
</simpara>
</listitem>
</varlistentry>
<varlistentry><term><anchor id="bbv2.builtin.features.dependency"/>
<literal>dependency</literal></term>
<listitem>
<simpara>
Introduces a dependency on the target named by the
value of this feature (so it will be brought
up-to-date whenever the target being declared is).
The dependency is not used in any other way. For example, in
application with plugins, the plugins are not used when linking
the application,
application might have dependency on its plugins, even though
, and
adds its usage requirements to the build properties
of the target being declared.
The primary use case is when you want
the usage requirements (such as <code>#include</code> paths) of some
library to be applied, but don't want to link to it.
<!-- It's hard to picture why anyone would want to do
that. Please flesh out this motivation -->
</simpara>
</listitem>
</varlistentry>
<varlistentry><term><anchor id="bbv2.builtin.features.use"/>
<literal>use</literal></term>
<listitem>
<simpara>
Introduces a dependency on the target named by the
value of this feature (so it will be brought
up-to-date whenever the target being declared is), and
adds its usage requirements to the build properties
<!-- Do you really mean "to the requirements?" -->
of the target being declared. The dependency is not used
in any other way. The primary use case is when you want
the usage requirements (such as <code>#include</code> paths) of some
library to be applied, but don't want to link to it.
<!-- It's hard to picture why anyone would want to do
that. Please flesh out this motivation -->
</simpara>
</listitem>
</varlistentry>
<varlistentry><term><anchor id="bbv2.builtin.features.dll-path"/>
<literal>dll-path</literal></term>
<listitem>
<simpara>
Specify an additional directory where the system should
look for shared libraries when the executable or shared
library is run. This feature only affects Unix
compilers. Plase see <xref linkend="bbv2.faq.dll-path"/>
in <xref linkend="bbv2.faq"/> for details.
</simpara>
</listitem></varlistentry>
<varlistentry><term><literal>hardcode-dll-paths</literal></term>
<listitem>
<simpara>
Controls automatic generation of dll-path properties.
</simpara>
<para><emphasis role="bold">Allowed values:</emphasis>
<literal>true</literal>, <literal>false</literal>. This property
is specific to Unix systems. If an executable is built with
<code>&lt;hardcode-dll-paths&gt;true</code>, the generated binary
will contain the list of all the paths to the used shared
libraries. As the result, the executable can be run without
changing system paths to shared libraries or installing the
libraries to system paths. This
<!-- you need an antecedent. This _what_? -->
is very convenient during
development. Plase see the <link
linkend="bbv2.faq.dll-path">FAQ entry</link> for details.
Note that on Mac OSX, the paths are unconditionally hardcoded by
the linker, and it's not possible to disable that behaviour.
</para>
</listitem></varlistentry>
<varlistentry>
<term><literal>cflags</literal></term>
<term><literal>cxxflags</literal></term>
<term><literal>linkflags</literal></term>
<listitem>
<simpara>
The value of those features is passed without modification to the
corresponding tools. For <code>cflags</code> that's both the C and C++
compilers, for <code>cxxflags</code> that's the C++ compiler and for
<code>linkflags</code> that's the linker. The features are handy when
you're trying to do something special that cannot be achieved by
higher-level feature in Boost.Build.
</simpara>
</listitem>
</varlistentry>
<varlistentry><term><literal>warnings</literal></term>
<listitem>
<simpara>
The <code>&lt;warnings&gt;</code> feature controls the warning level of compilers. It has the following values:
<itemizedlist>
<listitem><para><code>off</code> - disables all warnings.</para></listitem>
<listitem><para><code>on</code> - enables default warning level for the tool.</para></listitem>
<listitem><para><code>all</code> - enables all warnings.</para></listitem>
</itemizedlist>
Default value is <code>all</code>.
</simpara>
</listitem>
</varlistentry>
<varlistentry><term><literal>warnings-as-errors</literal></term>
<listitem>
<simpara>
The <code>&lt;warnings-as-errors&gt;</code> makes it possible to treat warnings as errors and abort
compilation on a warning. The value <code>on</code> enables this behaviour. The default value is
<code>off</code>.
</simpara>
</listitem>
</varlistentry>
<varlistentry><term><literal>build</literal></term>
<listitem>
<para><emphasis role="bold">Allowed values:</emphasis> <literal>no</literal></para>
<para>
The <code>build</code> feature is used to conditionally disable build of a target. If <code>&lt;build&gt;no</code>
is in properties when building a target, build of that target is skipped. Combined with conditional requirements this
allows to skip building some target in configurations where the build is known to fail.
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>tag</literal></term>
<listitem><para>The <literal>tag</literal> feature is used to customize
the name of the generated files. The value should have the form:
<programlisting>@<replaceable>rulename</replaceable></programlisting> where
<replaceable>rulename</replaceable> should be a name of a rule with
the following signature:
<programlisting>rule tag ( name : type ? : property-set )</programlisting>
The rule will be called for each target with the default name computed
by Boost.Build, the type of the target, and property set. The rule
can either return a string that must be used as the name of the
target, or empty string, in which case the default name will be used.
</para>
<para>Most typical use of the <literal>tag</literal> feature is
to encode build properties, or library version in library target names.
You should take care to return non-empty string from the tag rule
only for types you care about &#x2014; otherwise, you might
end up modifying names of object files, generated header file and
other targets for which changing names does not make sense.</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>debug-symbols</literal></term>
<listitem>
<para><emphasis role="bold">Allowed values:</emphasis> <literal>on</literal>, <literal>off</literal>.</para>
<para>The <literal>debug-symbols</literal> feature specifies if
produced object files, executables and libraries should include
debug information.
Typically, the value of this feature is implicitly set by the
<literal>variant</literal> feature, but it can be explicitly
specified by the user. The most common usage is to build
release variant with debugging information.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</chapter>

2
v2/doc/src/tutorial.xml
View File

@@ -521,7 +521,7 @@ alias foo : /other_project//bar/&lt;link&gt;static ;
exe e1 : e1.cpp foo ;
exe e10 : e10.cpp foo ;</programlisting>
The <link linkend="bbv2.builtins.alias"><functionname>alias</functionname></link>
The <link linkend="bbv2.tasks.alias"><functionname>alias</functionname></link>
rule is specifically used to rename a reference to a target and possibly
change the properties.

2
v2/roll.sh
View File

@@ -25,7 +25,7 @@ echo -e "boost-build kernel ;\n" > boost-build.jam
# Build the documentation
touch doc/project-root.jam
export BOOST_ROOT=/home/ghost/Work/boost-rc
export BOOST_BUILD_PATH=/home/ghost/Work/boost-rc/tools/build/v2
cd doc
/home/ghost/Work/boost-rc/tools/jam/src/bin.linuxx86/bjam --v2
/home/ghost/Work/boost-rc/tools/jam/src/bin.linuxx86/bjam --v2 pdf

2
v2/tools/builtin.jam
View File

@@ -222,7 +222,7 @@ feature instruction-set :
itanium itanium1 merced itanium2 mckinley
# Sparc
v7 cypress v8 supersparc sparclite hypersparc sparclite86x
f930 f934 sparclet tsc701 v9 ultrasparc
f930 f934 sparclet tsc701 v9 ultrasparc ultrasparc3
# RS/6000 & PowerPC
401 403 405 405fp 440 440fp 505
601 602 603 603e 604 604e 620 630 740 7400 7450 750

127
v2/tools/doxygen.jam
View File

@@ -33,6 +33,8 @@ import project ;
import xsltproc ;
import make ;
import os ;
import toolset : flags ;
import alias ;
# Use to specify extra configuration paramters. These get translated
# into a doxyfile which configures the building of the docs.
@@ -44,17 +46,29 @@ feature.feature prefix : : free ;
# Specify the "<xsl:param>boost.doxygen.reftitle" XSLT option.
feature.feature reftitle : : free ;
# Which processor to use for various translations from Doxygen.
feature.feature doxygen:processor : xsltproc doxproc : implicit ;
# To generate, or not, index sections.
feature.feature doxygen:doxproc:index : no yes : incidental ;
# The ID for the resulting BoostBook reference section.
feature.feature doxygen:doxproc:id : : free ;
# The title for the resulting BoostBook reference section.
feature.feature doxygen:doxproc:title : : free ;
# Doxygen configuration input file.
type.register DOXYFILE : doxyfile ;
# Doxygen XML multi-file output.
type.register DOXYGEN_XML_MULTIFILE : : XML ;
type.register DOXYGEN_XML_MULTIFILE : xml-dir : XML ;
# Doxygen XML coallesed output.
type.register DOXYGEN_XML : doxygen : XML ;
# Doxygen HTML multifile directory.
type.register DOXYGEN_HTML_MULTIFILE : dir : HTML ;
type.register DOXYGEN_HTML_MULTIFILE : html-dir : HTML ;
# Redirection HTML file to HTML multifile directory.
type.register DOXYGEN_HTML : : HTML ;
@@ -125,13 +139,24 @@ rule init ( name ? )
.doxygen = $(name) ;
}
.doxygen ?= doxygen ;
.doxproc = [ modules.binding $(__name__) ] ;
.doxproc = $(.doxproc:D)/doxproc.py ;
generators.register-composing doxygen.headers-to-doxyfile : H HPP CPP : DOXYFILE ;
generators.register-standard doxygen.run : DOXYFILE : DOXYGEN_XML_MULTIFILE ;
generators.register-standard doxygen.xml-to-boostbook : DOXYGEN_XML : BOOSTBOOK ;
generators.register-standard doxygen.collect : DOXYGEN_XML_MULTIFILE : DOXYGEN_XML ;
generators.register-standard doxygen.run : DOXYFILE : DOXYGEN_HTML_MULTIFILE ;
generators.register-standard doxygen.html-redirect : DOXYGEN_HTML_MULTIFILE : DOXYGEN_HTML ;
generators.register-composing doxygen.headers-to-doxyfile
: H HPP CPP : DOXYFILE ;
generators.register-standard doxygen.run
: DOXYFILE : DOXYGEN_XML_MULTIFILE ;
generators.register-standard doxygen.xml-dir-to-boostbook
: DOXYGEN_XML_MULTIFILE : BOOSTBOOK : <doxygen:processor>doxproc ;
generators.register-standard doxygen.xml-to-boostbook
: DOXYGEN_XML : BOOSTBOOK : <doxygen:processor>xsltproc ;
generators.register-standard doxygen.collect
: DOXYGEN_XML_MULTIFILE : DOXYGEN_XML ;
generators.register-standard doxygen.run
: DOXYFILE : DOXYGEN_HTML_MULTIFILE ;
generators.register-standard doxygen.html-redirect
: DOXYGEN_HTML_MULTIFILE : DOXYGEN_HTML ;
IMPORT $(__name__) : doxygen : : doxygen ;
}
@@ -153,18 +178,36 @@ actions doxygen-action
"$(NAME:E=doxygen)" $(>) && echo "Stamped" > "$(<)"
}
# Runs the Python doxproc XML processor.
actions doxproc
{
python "$(DOXPROC)" "--xmldir=$(>)" "--output=$(<)" "$(OPTIONS)" "--id=$(ID)" "--title=$(TITLE)"
}
# Generates a doxygen configuration file (doxyfile) given a set of C++
# sources and a property list that may contain <doxygen:param>
# features.
rule headers-to-doxyfile ( target : sources * : properties * )
{
local text "# Generated by Boost.Build version 2" ;
local output-dir ;
# Translate <doxygen:param> into command line flags.
for local param in [ feature.get-values <doxygen:param> : $(properties) ]
{
local namevalue = [ regex.match ([^=]*)=(.*) : $(param) ] ;
text += "$(namevalue[1]) = $(namevalue[2])" ;
if $(namevalue[1]) = OUTPUT_DIRECTORY
{
output-dir = "$(namevalue[2])" ;
}
}
if ! $(output-dir)
{
output-dir = [ on $(target) return $(LOCATE) ] ;
text += "OUTPUT_DIRECTORY = $(output-dir)" ;
}
local headers = "" ;
@@ -248,6 +291,19 @@ rule xml-to-boostbook ( target : source : properties * )
xsltproc.xslt $(target) : $(source) $(d2b-xsl) : $(xslt-properties) ;
}
flags doxygen.xml-dir-to-boostbook OPTIONS <doxygen:doxproc:index>yes : --enable-index ;
flags doxygen.xml-dir-to-boostbook ID <doxygen:doxproc:id> ;
flags doxygen.xml-dir-to-boostbook TITLE <doxygen:doxproc:title> ;
rule xml-dir-to-boostbook ( target : source : properties * )
{
DOXPROC on $(target) = $(.doxproc) ;
LOCATE on $(source:S=) = [ on $(source) return $(LOCATE) ] ;
doxygen.doxproc $(target) : $(source:S=) ;
}
# Generate the HTML redirect to HTML dir index.html file.
rule html-redirect ( target : source : properties * )
{
@@ -273,7 +329,7 @@ rule html-redirect ( target : source : properties * )
}
# User-level rule to generate BoostBook XML from a set of headers via Doxygen.
rule doxygen ( target : sources * : requirements * : default-build * )
rule doxygen ( target : sources * : requirements * : default-build * : usage-requirements * )
{
local project = [ project.current ] ;
@@ -325,24 +381,65 @@ rule doxygen ( target : sources * : requirements * : default-build * )
else
{
# Build a BoostBook XML file from the sources.
local doxyfile = [
new typed-target $(target) : $(project) : BOOSTBOOK
: [ targets.main-target-sources $(sources) : $(target) ]
local location-xml = [ feature.get-values <location> : $(requirements) ] ;
requirements = [ property.change $(requirements) : <location> ] ;
local target-xml = $(target:B=$(target:B)-xml) ;
## The doxygen configuration file.
targets.main-target-alternative
[ new typed-target $(target-xml:S=.tag) : $(project) : DOXYFILE
: [ targets.main-target-sources $(sources) : $(target-xml:S=.tag) ]
: [ targets.main-target-requirements $(requirements)
<doxygen:param>GENERATE_HTML=NO
<doxygen:param>GENERATE_XML=YES
<doxygen:param>XML_OUTPUT=$(target-xml)
: $(project) ]
: [ targets.main-target-default-build $(default-build) : $(project) ]
] ;
targets.main-target-alternative $(doxyfile) ;
$(project).mark-target-as-explicit $(target-xml:S=.tag) ;
## The Doxygen XML directory of the processed source files.
targets.main-target-alternative
[ new typed-target $(target-xml:S=.dir) : $(project) : DOXYGEN_XML_MULTIFILE
: $(target-xml:S=.tag)
: [ targets.main-target-requirements $(requirements)
: $(project) ]
: [ targets.main-target-default-build $(default-build) : $(project) ]
] ;
$(project).mark-target-as-explicit $(target-xml:S=.dir) ;
## The resulting BoostBook file is generated by the processor tool. The
## tool can be either the xsltproc plus accompanying XSL scripts. Or it
## can be the python doxproc script.
targets.main-target-alternative
[ new typed-target $(target-xml) : $(project) : BOOSTBOOK
: $(target-xml:S=.dir)
: [ targets.main-target-requirements $(requirements)
: $(project) ]
: [ targets.main-target-default-build $(default-build) : $(project) ]
] ;
$(project).mark-target-as-explicit $(target-xml) ;
targets.main-target-alternative
[ new install-target-class $(target:S=.xml) : $(project)
: [ $(doxyfile).name ]
: $(target-xml)
: [ targets.main-target-requirements $(requirements)
<location>.
<location>$(location-xml:E=.)
<name>$(target:S=.xml)
: $(project) ]
: [ targets.main-target-default-build $(default-build) : $(project) ]
] ;
$(project).mark-target-as-explicit $(target:S=.xml) ;
targets.main-target-alternative
[ new alias-target-class $(target) : $(project)
:
: [ targets.main-target-requirements $(requirements)
: $(project) ]
: [ targets.main-target-default-build $(default-build) : $(project) ]
: [ targets.main-target-usage-requirements $(usage-requirements)
<dependency>$(target:S=.xml)
: $(project) ]
] ;
}
}

110
v2/tools/gcc.jam
View File

@@ -654,3 +654,113 @@ else if [ modules.peek : UNIX ]
}
}
}
local rule cpu-flags ( toolset variable : architecture : instruction-set + : values + : default ? )
{
if $(default)
{
flags $(toolset) $(variable)
<architecture>$(architecture)/<instruction-set>
: $(values) ;
}
flags $(toolset) $(variable)
<architecture>/<instruction-set>$(instruction-set)
<architecture>$(architecture)/<instruction-set>$(instruction-set)
: $(values) ;
}
# Set architecture/instruction-set options.
#
# x86 and compatible
flags gcc OPTIONS <architecture>x86/<address-model>32 : -m32 ;
flags gcc OPTIONS <architecture>x86/<address-model>64 : -m64 ;
cpu-flags gcc OPTIONS : x86 : i386 : -march=i386 : default ;
cpu-flags gcc OPTIONS : x86 : i486 : -march=i486 ;
cpu-flags gcc OPTIONS : x86 : i586 : -march=i586 ;
cpu-flags gcc OPTIONS : x86 : i686 : -march=i686 ;
cpu-flags gcc OPTIONS : x86 : pentium : -march=pentium ;
cpu-flags gcc OPTIONS : x86 : pentium-mmx : -march=pentium-mmx ;
cpu-flags gcc OPTIONS : x86 : pentiumpro : -march=pentiumpro ;
cpu-flags gcc OPTIONS : x86 : pentium2 : -march=pentium2 ;
cpu-flags gcc OPTIONS : x86 : pentium3 : -march=pentium3 ;
cpu-flags gcc OPTIONS : x86 : pentium3m : -march=pentium3m ;
cpu-flags gcc OPTIONS : x86 : pentium-m : -march=pentium-m ;
cpu-flags gcc OPTIONS : x86 : pentium4 : -march=pentium4 ;
cpu-flags gcc OPTIONS : x86 : pentium4m : -march=pentium4m ;
cpu-flags gcc OPTIONS : x86 : prescott : -march=prescott ;
cpu-flags gcc OPTIONS : x86 : nocona : -march=nocona ;
cpu-flags gcc OPTIONS : x86 : k6 : -march=k6 ;
cpu-flags gcc OPTIONS : x86 : k6-2 : -march=k6-2 ;
cpu-flags gcc OPTIONS : x86 : k6-3 : -march=k6-3 ;
cpu-flags gcc OPTIONS : x86 : athlon : -march=athlon ;
cpu-flags gcc OPTIONS : x86 : athlon-tbird : -march=athlon-tbird ;
cpu-flags gcc OPTIONS : x86 : athlon-4 : -march=athlon-4 ;
cpu-flags gcc OPTIONS : x86 : athlon-xp : -march=athlon-xp ;
cpu-flags gcc OPTIONS : x86 : athlon-mp : -march=athlon-mp ;
##
cpu-flags gcc OPTIONS : x86 : k8 : -march=k8 ;
cpu-flags gcc OPTIONS : x86 : opteron : -march=opteron ;
cpu-flags gcc OPTIONS : x86 : athlon64 : -march=athlon64 ;
cpu-flags gcc OPTIONS : x86 : athlon-fx : -march=athlon-fx ;
cpu-flags gcc OPTIONS : x86 : winchip-c6 : -march=winchip-c6 ;
cpu-flags gcc OPTIONS : x86 : winchip2 : -march=winchip2 ;
cpu-flags gcc OPTIONS : x86 : c3 : -march=c3 ;
cpu-flags gcc OPTIONS : x86 : c3-2 : -march=c3-2 ;
# Sparc
flags gcc OPTIONS <architecture>sparc/<address-model>32 : -m32 ;
flags gcc OPTIONS <architecture>sparc/<address-model>64 : -m64 ;
cpu-flags gcc OPTIONS : sparc : c3 : -mcpu=c3 : default ;
cpu-flags gcc OPTIONS : sparc : v7 : -mcpu=v7 ;
cpu-flags gcc OPTIONS : sparc : cypress : -mcpu=cypress ;
cpu-flags gcc OPTIONS : sparc : v8 : -mcpu=v8 ;
cpu-flags gcc OPTIONS : sparc : supersparc : -mcpu=supersparc ;
cpu-flags gcc OPTIONS : sparc : sparclite : -mcpu=sparclite ;
cpu-flags gcc OPTIONS : sparc : hypersparc : -mcpu=hypersparc ;
cpu-flags gcc OPTIONS : sparc : sparclite86x : -mcpu=sparclite86x ;
cpu-flags gcc OPTIONS : sparc : f930 : -mcpu=f930 ;
cpu-flags gcc OPTIONS : sparc : f934 : -mcpu=f934 ;
cpu-flags gcc OPTIONS : sparc : sparclet : -mcpu=sparclet ;
cpu-flags gcc OPTIONS : sparc : tsc701 : -mcpu=tsc701 ;
cpu-flags gcc OPTIONS : sparc : v9 : -mcpu=v9 ;
cpu-flags gcc OPTIONS : sparc : ultrasparc : -mcpu=ultrasparc ;
cpu-flags gcc OPTIONS : sparc : ultrasparc3 : -mcpu=ultrasparc3 ;
# RS/6000 & PowerPC
flags gcc OPTIONS <architecture>power/<address-model>32 : -m32 ;
flags gcc OPTIONS <architecture>power/<address-model>64 : -m64 ;
flags gcc OPTIONS <architecture>power/<address-model>/<instruction-set> : -mcpu=common ;
cpu-flags gcc OPTIONS : power : 403 : -mcpu=403 ;
cpu-flags gcc OPTIONS : power : 505 : -mcpu=505 ;
cpu-flags gcc OPTIONS : power : 601 : -mcpu=601 ;
cpu-flags gcc OPTIONS : power : 602 : -mcpu=602 ;
cpu-flags gcc OPTIONS : power : 603 : -mcpu=603 ;
cpu-flags gcc OPTIONS : power : 603e : -mcpu=603e ;
cpu-flags gcc OPTIONS : power : 604 : -mcpu=604 ;
cpu-flags gcc OPTIONS : power : 604e : -mcpu=604e ;
cpu-flags gcc OPTIONS : power : 620 : -mcpu=620 ;
cpu-flags gcc OPTIONS : power : 630 : -mcpu=630 ;
cpu-flags gcc OPTIONS : power : 740 : -mcpu=740 ;
cpu-flags gcc OPTIONS : power : 7400 : -mcpu=7400 ;
cpu-flags gcc OPTIONS : power : 7450 : -mcpu=7450 ;
cpu-flags gcc OPTIONS : power : 750 : -mcpu=750 ;
cpu-flags gcc OPTIONS : power : 801 : -mcpu=801 ;
cpu-flags gcc OPTIONS : power : 821 : -mcpu=821 ;
cpu-flags gcc OPTIONS : power : 823 : -mcpu=823 ;
cpu-flags gcc OPTIONS : power : 860 : -mcpu=860 ;
cpu-flags gcc OPTIONS : power : 970 : -mcpu=970 ;
cpu-flags gcc OPTIONS : power : 8540 : -mcpu=8540 ;
cpu-flags gcc OPTIONS : power : power : -mcpu=power ;
cpu-flags gcc OPTIONS : power : power2 : -mcpu=power2 ;
cpu-flags gcc OPTIONS : power : power3 : -mcpu=power3 ;
cpu-flags gcc OPTIONS : power : power4 : -mcpu=power4 ;
cpu-flags gcc OPTIONS : power : power5 : -mcpu=power5 ;
cpu-flags gcc OPTIONS : power : powerpc : -mcpu=powerpc ;
cpu-flags gcc OPTIONS : power : powerpc64 : -mcpu=powerpc64 ;
cpu-flags gcc OPTIONS : power : rios : -mcpu=rios ;
cpu-flags gcc OPTIONS : power : rios1 : -mcpu=rios1 ;
cpu-flags gcc OPTIONS : power : rios2 : -mcpu=rios2 ;
cpu-flags gcc OPTIONS : power : rsc : -mcpu=rsc ;
cpu-flags gcc OPTIONS : power : rs64a : -mcpu=rs64 ;
# AIX variant of RS/6000 & PowerPC
flags gcc OPTIONS <architecture>power/<address-model>32/<target-os>aix : -maix32 ;
flags gcc OPTIONS <architecture>power/<address-model>64/<target-os>aix : -maix64 ;
flags gcc AROPTIONS <architecture>power/<address-model>64/<target-os>aix : "-X 64" ;

21
v2/tools/kylix.jam
View File

@@ -1,21 +0,0 @@
# Copyright 2003 Vladimir Prus
# Distributed under the Boost Software License, Version 1.0.
# (See accompanying file LICENSE_1_0.txt or http://www.boost.org/LICENSE_1_0.txt)
# Support for the Borland's Kylix command line compiler
import toolset ;
toolset.register kylix ;
toolset.inherit kylix : borland ;
COMPILER_NAME = bc++ ;
LINKER_NAME = bc++ ;
actions link bind LIBRARIES
{
$(LINKER_NAME) $(OPTIONS) -q -L$(LINKPATH) -e$(<[1]) $(>) $(LIBRARIES) lib$(FINDLIBS-ST).a lib$(FINDLIBS-SA).so
}