2
0
mirror of https://github.com/boostorg/build.git synced 2026-02-17 01:32:12 +00:00

Some renames:

- 'stage' -> 'install'
- 'traverse-dependencies' -> 'install-dependencies'
- 'include-type' -> 'install-type'.


[SVN r26833]
This commit is contained in:
Vladimir Prus
2005-01-24 10:08:07 +00:00
parent 3e4ae30d8d
commit c40b9809ee
4 changed files with 94 additions and 103 deletions

View File

@@ -1399,30 +1399,31 @@ exe main : main.cpp lib_alias ;
<title>Installing</title>
<para>For installing a built target you should use the
<code>stage</code> rule, which follows the <link
<code>install</code> rule, which follows the <link
linkend="bbv2.main-target-rule-syntax">common syntax</link>. For
example:
<programlisting>
stage dist : hello helpers ;
install dist : hello helpers ;
</programlisting>
will cause the targets <code>hello</code> and <code>helpers</code> to
be moved to the <filename>dist</filename> directory. <!-- relative to what? --> The directory can
be moved to the <filename>dist</filename> directory, relative to
Jamfile's directory. The directory can
be changed with the <code>location</code> property:
<programlisting>
stage dist : hello helpers : &lt;location&gt;/usr/bin ;
install dist : hello helpers : &lt;location&gt;/usr/bin ;
</programlisting>
While you can achieve the same effect by changing the target name to
<filename>/usr/bin</filename>, using the <code>location</code>
property is better because it allows you to use a memnonic target name on the
command line and in other targets. <!-- do you really need "on the...?" -->
property is better, because it allows you to use a memnonic target
name.
</para>
<para>The <code>location</code> property is especially handy when the location
is not fixed, but depends on build variant or environment variables:
<programlisting>
stage dist : hello helpers : &lt;variant&gt;release:&lt;location&gt;dist/release
install dist : hello helpers : &lt;variant&gt;release:&lt;location&gt;dist/release
&lt;variant&gt;debug:&lt;location&gt;dist/debug ;
stage dist2 : hello helpers : &lt;location&gt;$(DIST) ;
install dist2 : hello helpers : &lt;location&gt;$(DIST) ;
</programlisting>
See also <link linkend="bbv2.reference.variants.propcond">conditional
properties</link> and <link linkend="bbv2.faq.envar">environment variables</link>
@@ -1430,18 +1431,13 @@ stage dist2 : hello helpers : &lt;location&gt;$(DIST) ;
<para>
Specifying the names of all libraries to install can be boring. The
<code>stage</code> allows to specify only the top-level executable
<code>install</code> allows you to specify only the top-level executable
targets to install, and automatically install all dependencies:
<programlisting>
stage dist : hello
: &lt;traverse-dependencies&gt;on &lt;include-type&gt;EXE
&lt;include-type&gt;LIB
install dist : hello
: &lt;install-dependencies&gt;on &lt;install-type&gt;EXE
&lt;install-type&gt;LIB
;
<!-- I dislike the names being used here. “include” already has a
different meaning, and “traverse” is just vague—it isn't clear
what happens when those dependencies are traversed. You could
replace both names with “install” and it would be an improvement
-->
</programlisting>
will find all targets that <code>hello</code> depends on, and install
all of the which are either executables or libraries. More
@@ -1459,12 +1455,33 @@ stage dist : hello
rule can be used when targets must be installed into several
directories:
<programlisting>
alias install : install-bin install-lib ;
stage install-bin : applications : /usr/bin ;
stage install-lib : helper : /usr/lib ;
install install : install-bin install-lib ;
install install-bin : applications : /usr/bin ;
install install-lib : helper : /usr/lib ;
</programlisting>
</para>
<para>Because the <code>install</code> rule just copies targets, most
free features <footnote><para>see the definition of "free" in <xref
linkend="bbv2.reference.features.attributes"/>.</para></footnote>
have no effect when used in requirements of the <code>install</code>.
The only two which matter are
<link linkend="bbv2.builtin.features.dependency">
<varname>dependency</varname></link> and, on Unix,
<varname>dll-path</varname>.
</para>
<note>
<para>
(Unix specific). On Unix, executables built with Boost.Build typically
contain the list of paths to all used dynamic libraries. For
installing, this is not desired, so Boost.Build relinks the executable
with an empty list of paths. You can also specify additional paths for
installed executables with the <varname>dll-path</varname> feature.
</para>
</note>
</section>
<section id="bbv2.builtins.testing">
@@ -1581,8 +1598,31 @@ unit-test helpers_test : helpers_test.cpp helpers ;
</simpara>
</listitem>
</varlistentry>
<varlistentry><term><anchor id="bbv2.builtin.features.dependency"/>
<literal>dependency</literal></term>
<listitem>
<simpara>
<!-- vp: I'm just copy-pasting the description of
'use', so that I can document 'stage'. I'll clean things up
when I get to editing this part -->
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.use"/>
<literal>use</literal></term>

View File

@@ -128,7 +128,7 @@ foo() { }
t.write("Jamfile", """
lib l : l.cpp ;
exe a : a.cpp l ;
stage dist : a : <traverse-dependencies>on <include-type>EXE <include-type>LIB ;
stage dist : a : <install-dependencies>on <install-type>EXE <install-type>LIB ;
""")
t.write("project-root.jam", "")
@@ -147,7 +147,7 @@ lib l2 : l2.cpp ;
lib l3 : l3.cpp ;
lib l : l.cpp : <use>l2 <dependency>l3 ;
exe a : a.cpp l ;
stage dist : a : <traverse-dependencies>on <include-type>EXE <include-type>LIB ;
stage dist : a : <install-dependencies>on <install-type>EXE <install-type>LIB ;
""")
t.rm("dist")

View File

@@ -172,7 +172,7 @@ rule doxygen ( target-name : sources * : requirements * : default-build * )
targets.main-target-alternative $(doxyfile) ;
targets.main-target-alternative
[ new stage-target-class $(target-name:S=.xml) : $(project)
[ new install-target-class $(target-name:S=.xml) : $(project)
: [ $(doxyfile).name ]
: [ targets.main-target-requirements $(requirements) <location>. : $(project) ]
: [ targets.main-target-default-build $(default-build) : $(project) ]

View File

@@ -3,54 +3,8 @@
# all copies. This software is provided "as is" without express or implied
# warranty, and with no claim as to its suitability for any purpose.
# This module defines the 'stage' rule, used to copy a set of targets to
# This module defines the 'install' rule, used to copy a set of targets to
# a single location
#
# Typical usage:
#
# stage dist : hello_world : <location>/usr/bin ;
#
# The source target will be copied to the specified location. Some targets will
# we specially processed. In particular, binaries will be relinked. Free properties
# from stage dist will be included to properties used for relinking. For example
#
# stage dist : hello_world : <location>/usr/bin <dll-path>/opt/lib ;
#
# will cause 'hello_world' to be relinked to the new location, and <dll-path>
# property will be added when relinking.
#
# The following properties specifically control 'stage' rule.
#
# - <location> tells where to put targets. If not specified, directory
# with the same name as stage name will be used.
#
# - <name> tells the new name of the staged target. In this case, only
# one target can be specified in sources.
#
# - <so-version> is Unix specific. It causes all staged libraries to have
# value of the feature added to the end of name. The libraries will be
# relinked during staging, so that 'soname' embedded inside the library
# has the version suffix too.
# The stage rule can also traverse dependencies, for example to install a
# program an all required libraries. Two properties affect this.
#
# - <traverse-dependencies>on tells that dependencies should be traversed.
# For each target in 'stage' sources, all sources to that target and all
# dependency properties are traversed. Sources and dependecy properties of
# those target are traversed recursively.
#
# - <include-type>SOME_TYPE tells that targets of SOME_TYPE or a type derived
# from SOME_TYPE, should be included.
# If no such property is specified, then all found targets will be staged.
# Otherwise, only targets with types mentioned in <include-type> property
# will be included.
#
# Example usage::
#
# stage dist : hello_world :
# <traverse-dependencies>on <include-type>EXE <include-type>SHARED_LIB ;
#
import targets ;
import "class" : new ;
@@ -65,11 +19,11 @@ import project ;
import property-set ;
import virtual-target ;
feature.feature <traverse-dependencies> : off on : incidental ;
feature.feature <include-type> : : free incidental ;
feature.feature <install-dependencies> : off on : incidental ;
feature.feature <install-type> : : free incidental ;
feature.feature <so-version> : : free incidental ;
class stage-target-class : basic-target
class install-target-class : basic-target
{
import feature project type errors generators path stage ;
import "class" : new ;
@@ -191,12 +145,13 @@ class stage-target-class : basic-target
local result ;
# Traverse the dependencies, if needed.
if [ $(property-set).get <traverse-dependencies> ] = "on"
if [ $(property-set).get <install-dependencies> ] = "on"
{
source-targets = [ collect-targets $(source-targets) ] ;
}
# Filter the target types, if needed
local included-types = [ $(property-set).get <install-type> ] ;
for local r in $(source-targets)
{
local ty = [ $(r).type ] ;
@@ -230,16 +185,6 @@ class stage-target-class : basic-target
result += $(r) ;
}
}
local included-types = [ $(property-set).get <include-type> ] ;
if $(included-types)
{
}
else
{
}
return $(result) ;
}
@@ -323,33 +268,40 @@ rule relink-file ( project : source : property-set )
return $(result) ;
}
# Declare staged version of the EXE type. Generator for this type will
# Declare installed version of the EXE type. Generator for this type will
# cause relinking to the new location.
type.register STAGED_EXE : : EXE ;
type.register INSTALLED_EXE : : EXE ;
class stage-exe-generator : generator
class installed-exe-generator : generator
{
import type property-set modules stage ;
rule __init__ ( )
{
generator.__init__ stage-exe : EXE : STAGED_EXE ;
generator.__init__ install-exe : EXE : INSTALLED_EXE ;
}
rule run ( project name ? : property-set : source : multiple ? )
{
return [ stage.relink-file $(project) : $(source) : $(property-set) ] ;
if [ $(property-set).get <os> ] = NT
{
# Relinking is never needed on NT
return [ stage.copy-file $(project)
: $(source) : $(property-set) ] ;
}
else
{
return [ stage.relink-file $(project)
: $(source) : $(property-set) ] ;
}
}
}
generators.register [ new stage-exe-generator ] ;
generators.register [ new installed-exe-generator ] ;
# Declares a stage target. When build, it will construct all sources
# and place in one directory. The directory can be specified in requirements
# with 'location' property. If not specified, the directory name will be
# the same as target name, relative to the project where the target
# is declared.
rule stage ( name : sources * : requirements * : default-build * )
# Main target rule for 'install'
rule install ( name : sources * : requirements * : default-build * )
{
local project = [ project.current ] ;
@@ -373,14 +325,15 @@ rule stage ( name : sources * : requirements * : default-build * )
}
targets.main-target-alternative
[ new stage-target-class $(name) : $(project)
[ new install-target-class $(name) : $(project)
: [ targets.main-target-sources $(sources) : $(name) ]
: [ targets.main-target-requirements $(requirements) : $(project) ]
: [ targets.main-target-default-build $(default-build) : $(project) ]
] ;
}
IMPORT $(__name__) : stage : : stage ;
IMPORT $(__name__) : install : : install ;
IMPORT $(__name__) : install : : stage ;
rule add-variant-and-compiler ( name : property-set )
{
@@ -391,8 +344,6 @@ rule add-variant ( name : type ? : property-set )
{
return [ rename $(name) : $(type) : $(property-set) : unversioned ] ;
}
IMPORT $(__name__) : add-variant add-variant-and-compiler
: : stage.add-variant stage.add-variant-and-compiler ;
rule rename ( name : type ? : property-set : unversioned ? )
{