1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Dependent Targets</title>
<link rel="stylesheet" href="../../boostbook.css" type="text/css">
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
<link rel="start" href="../../index.html" title="Boost.Build V2 User Manual">
<link rel="up" href="../tutorial.html" title="Chapter3.Tutorial">
<link rel="prev" href="hierarchy.html" title="Project Hierarchies">
<link rel="next" href="testing.html" title="Testing">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<table cellpadding="2" width="100%"><tr><td valign="top"><img alt="Boost C++ Libraries" width="277" height="86" src="../../../../boost.png"></td></tr></table>
<hr>
<div class="spirit-nav">
<a accesskey="p" href="hierarchy.html"><img src="../../../../doc/html/images/prev.png" alt="Prev"></a><a accesskey="u" href="../tutorial.html"><img src="../../../../doc/html/images/up.png" alt="Up"></a><a accesskey="h" href="../../index.html"><img src="../../../../doc/html/images/home.png" alt="Home"></a><a accesskey="n" href="testing.html"><img src="../../../../doc/html/images/next.png" alt="Next"></a>
</div>
<div class="section" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="bbv2.tutorial.libs"></a>Dependent Targets</h2></div></div></div>
<p>
When a building a target <code class="filename">X</code> depends on first
building another target <code class="filename">Y</code> (such as a
library that must be linked with <em class="firstterm">X</em>),
<code class="filename">Y</code> is called a
<em class="firstterm">dependency</em> of <code class="filename">X</code> and
<code class="filename">X</code> is termed a
<em class="firstterm">dependent</em> of <code class="filename">Y</code>.
</p>
<p>To get a feeling of target dependencies, let's continue the
above example and see how <code class="filename">top/app/Jamfile</code> can
use libraries from <code class="filename">top/util/foo</code>. If
<code class="filename">top/util/foo/Jamfile</code> contains
</p>
<pre class="programlisting">
lib bar : bar.cpp ;
</pre>
<p>
then to use this library in <code class="filename">top/app/Jamfile</code>, we can
write:
</p>
<pre class="programlisting">
exe app : app.cpp ../util/foo//bar ;
</pre>
<p>
While <code class="computeroutput">app.cpp</code> refers to a regular source file,
<code class="computeroutput">../util/foo//bar</code> is a reference to another target:
a library <code class="filename">bar</code> declared in the Jamfile at
<code class="filename">../util/foo</code>.
</p>
<div class="tip"><table border="0" summary="Tip">
<tr>
<td rowspan="2" align="center" valign="top" width="25"><img alt="[Tip]" src="../../../../doc/html/images/tip.png"></td>
<th align="left">Tip</th>
</tr>
<tr><td align="left" valign="top"><p>Some other build system have special syntax for listing dependent
libraries, for example <code class="varname">LIBS</code> variable. In Boost.Build,
you just add the library to the list of sources.
</p></td></tr>
</table></div>
<p>Suppose we build <code class="filename">app</code> with:
</p>
<pre class="screen">
bjam app optimization=full define=USE_ASM
</pre>
<p>
Which properties will be used to build <code class="computeroutput">foo</code>? The answer is
that some features are
<em class="firstterm">propagated</em>—Boost.Build attempts to use
dependencies with the same value of propagated features. The
<code class="varname"><optimization></code> feature is propagated, so both
<code class="filename">app</code> and <code class="filename">foo</code> will be compiled
with full optimization. But <code class="varname"><define></code> is not
propagated: its value will be added as-is to the compiler flags for
<code class="filename">a.cpp</code>, but won't affect <code class="filename">foo</code>.
</p>
<p>Let's improve this project further.
The library
probably has some headers that must be used when compiling
<code class="filename">app.cpp</code>. We could manually add the necessary
<code class="computeroutput">#include</code> paths to <code class="filename">app</code>'s
requirements as values of the
<code class="varname"><include></code> feature, but then this work will
be repeated for all programs
that use <code class="filename">foo</code>. A better solution is to modify
<code class="filename">util/foo/Jamfile</code> in this way:
</p>
<pre class="programlisting">
project
: usage-requirements <include>.
;
lib foo : foo.cpp ;
</pre>
<p>
Usage requirements are applied not to the target being declared
but to its
dependents. In this case, <code class="literal"><include>.</code> will be applied to all
targets that directly depend on <code class="filename">foo</code>.
</p>
<p>Another improvement is using symbolic identifiers to refer to
the library, as opposed to <code class="filename">Jamfile</code> location.
In a large project, a library can be used by many targets, and if
they all use <code class="filename">Jamfile</code> location,
a change in directory organization entails much work.
The solution is to use project ids—symbolic names
not tied to directory layout. First, we need to assign a project id by
adding this code to
<code class="filename">Jamroot</code>:</p>
<pre class="programlisting">
use-project /library-example/foo : util/foo ;
</pre>
<p>Second, we modify <code class="filename">app/Jamfile</code> to use the
project id:
</p>
<pre class="programlisting">
exe app : app.cpp /library-example/foo//bar ;
</pre>
<p>
The <code class="filename">/library-example/foo//bar</code> syntax is used
to refer to the target <code class="filename">bar</code> in
the project with id <code class="filename">/library-example/foo</code>.
We've achieved our goal—if the library is moved to a different
directory, only <code class="filename">Jamroot</code> must be modified.
Note that project ids are global—two Jamfiles are not
allowed to assign the same project id to different directories.
</p>
<div class="tip"><table border="0" summary="Tip">
<tr>
<td rowspan="2" align="center" valign="top" width="25"><img alt="[Tip]" src="../../../../doc/html/images/tip.png"></td>
<th align="left">Tip</th>
</tr>
<tr><td align="left" valign="top">
<p>If you want all applications in some project to link
to a certain library, you can avoid having to specify it directly the sources of every
target by using the
<code class="varname"><library></code> property. For example, if <code class="filename">/boost/filesystem//fs</code>
should be linked to all applications in your project, you can add
<code class="computeroutput"><library>/boost/filesystem//fs</code> to the project's requirements, like this:</p>
<pre class="programlisting">
project
: requirements <source>/boost/filesystem//fs
;
</pre>
</td></tr>
</table></div>
</div>
<table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr>
<td align="left"></td>
<td align="right"><small></small></td>
</tr></table>
<hr>
<div class="spirit-nav">
<a accesskey="p" href="hierarchy.html"><img src="../../../../doc/html/images/prev.png" alt="Prev"></a><a accesskey="u" href="../tutorial.html"><img src="../../../../doc/html/images/up.png" alt="Up"></a><a accesskey="h" href="../../index.html"><img src="../../../../doc/html/images/home.png" alt="Home"></a><a accesskey="n" href="testing.html"><img src="../../../../doc/html/images/next.png" alt="Next"></a>
</div>
</body>
</html>
|
