mirror of
https://github.com/boostorg/build.git
synced 2026-02-16 01:12:13 +00:00
Add documentation for:
* Requirement Rules; std::locale-support, std::facet-support, and common-variant-tag * Install Descriptions; install, install-subinclude, and install-source. [SVN r20824]
This commit is contained in:
@@ -145,6 +145,10 @@
|
||||
|
||||
<li><a href="#external_project">Using External Projects</a></li>
|
||||
|
||||
<li><a href="#requirement_rules">Requirement Rules</a></li>
|
||||
|
||||
<li><a href="#install_descriptions">Install Descriptions</a></li>
|
||||
|
||||
<li><a href="#feature_description">Feature Descriptions</a></li>
|
||||
|
||||
<li><a href="#variant_description">Variant Descriptions</a></li>
|
||||
@@ -1068,6 +1072,131 @@ project boost : /home/dave/boost-cvs ;
|
||||
</pre>
|
||||
</blockquote>in your target's list of sources.
|
||||
|
||||
<h3><a name="requirement_rules">Requirement Rules</a></h3>
|
||||
|
||||
<p>Target requirements support the use of auxiliary rules to allow for more
|
||||
complex descitions about the requirements. If specified, by using the name
|
||||
of a rule in the requirements, the rule is called with the signature: <tt>(
|
||||
toolset variant : subvariant-path properties * )</tt> and should return the
|
||||
modified set of properties. There are a number of built-in rules for some
|
||||
common tasks that Boost uses, and you can use:</p>
|
||||
|
||||
<blockquote>
|
||||
<table border="1" summary="Built In Requirement Rules">
|
||||
<tr>
|
||||
<th>Rule</th>
|
||||
|
||||
<th>Effects</th>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><tt>std::locale-support</tt></td>
|
||||
|
||||
<td>Ensures that locale support is available for the target. For
|
||||
example some toolsets, like CodeWarrior, locale support is only
|
||||
available on specific platforms using a static runtime.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><tt>std::facet-support</tt></td>
|
||||
|
||||
<td>Ensures that facet support is available for the target.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><tt>common-variant-tag</tt></td>
|
||||
|
||||
<td>
|
||||
<p>Adds a constructed prefix tag to the target to conform to the
|
||||
Boost common naming conventions for libraries. The tag is
|
||||
constructed as:</p>
|
||||
|
||||
<blockquote>
|
||||
[-<toolset-tag>][-<thread-tag>][-<runtime-tag>][-<version-tag>]
|
||||
</blockquote>
|
||||
|
||||
<ul>
|
||||
<li><toolset-tag> maps to an abbreviated name of the
|
||||
toolset and when possible, and applicable, the version of the
|
||||
toolset.</li>
|
||||
|
||||
<li><thread-tag> "mt" when multi-threading is enabled.</li>
|
||||
|
||||
<li><runtime-tag> adds these single letter tags:<br>
|
||||
"s" when static linking to runtime<br>
|
||||
"g" when linking to debug runtime<br>
|
||||
"y" when building debug-python variants<br>
|
||||
"d" when building debug variants<br>
|
||||
"p" when building with stlport libraries<br>
|
||||
"n" when building with stlport and using native
|
||||
iostreams</li>
|
||||
|
||||
<li><version-tag> adds "major_minor" from a
|
||||
<tt><version></tt> property. Defaults to using
|
||||
$(BOOST_VERSION) if no version property is present.</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
</blockquote>
|
||||
|
||||
<h3><a name="install_descriptions">Install Descriptions</a></h3>
|
||||
|
||||
<p>Installable files and tergets are described with:</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
install <i>name</i> <i>type</i> : <i>sources</i>... : [<i>options</i>]... ;
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>Install descriptions define files and targets that can be installed by
|
||||
use of a <tt>stage</tt> target.</p>
|
||||
|
||||
<ul>
|
||||
<li><i>name</i> specifies the name to group the given files and targets
|
||||
as a collective entity. Multiple <tt>install</tt> descriptions can use
|
||||
the same name, in which case they are all collected into a single
|
||||
group.<br>
|
||||
<br></li>
|
||||
|
||||
<li><i>type</i> indicates the type of files specified by the
|
||||
<tt>install</tt>. This is used to later install files from different
|
||||
groups but with the same type.<br>
|
||||
<br></li>
|
||||
|
||||
<li><i>sources</i> can list both generated targets like
|
||||
<tt><exe>test_exe</tt> and individual files, but not template
|
||||
targets.<br>
|
||||
<br></li>
|
||||
|
||||
<li><i>options</i> additional options, currently none defined.<br></li>
|
||||
</ul>
|
||||
|
||||
<p>Install descriptions are meant to be used by <tt>stage</tt> targets to
|
||||
collect the various sources of many install descriptions into one or more
|
||||
destination directories. For this there are two rules that help in getting
|
||||
the sources specified:</p>
|
||||
|
||||
<ul>
|
||||
<li><tt>install-subinclude <i>jamfiles</i>... :
|
||||
[<i>options</i>]...</tt><br>
|
||||
<br>
|
||||
Includes the listed Jamfiles to read in the install descriptions.
|
||||
Multiple <tt><exclude><i>name</i></tt> options can be used to
|
||||
exclude the named groups of install descriptions from getting
|
||||
defined.<br>
|
||||
<br></li>
|
||||
|
||||
<li><tt>install-source <i>type</i></tt><br>
|
||||
<br>
|
||||
Returns the list of sources and targets specified by the install for the
|
||||
given type. The returned list can be used as the sources for a
|
||||
<tt>stage</tt> target which would place all the sources into that
|
||||
stage.<br>
|
||||
<br></li>
|
||||
</ul>
|
||||
|
||||
<h3><a name="feature_description">Feature Descriptions</a></h3>
|
||||
|
||||
<p>Features are described by stating the feature type (simple features are
|
||||
@@ -1410,9 +1539,9 @@ flags msvc HDRS <include> ;
|
||||
|
||||
<p>Revised
|
||||
<!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan
|
||||
-->8 September, 2003
|
||||
-->8 September, 2003
|
||||
<!--webbot bot="Timestamp" endspan i-checksum="13972"
|
||||
--></p>
|
||||
--></p>
|
||||
|
||||
<p>Copyright © Dave Abrahams 2001.</p>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user