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
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
|
<!--
__COPYRIGHT__
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-->
<para>
The experience of configuring any
software build tool to build a large code base
usually, at some point,
involves trying to figure out why
the tool is behaving a certain way,
and how to get it to behave the way you want.
&SCons; is no different.
</para>
<section>
<title>Why is That Target Being Rebuilt? the &debug-explain; Option</title>
<para>
Let's take a simple example of
a misconfigured build
that causes a target to be rebuilt
every time &SCons; is run:
</para>
<programlisting>
# Intentionally misspell the output file name in the
# command used to create the file:
Command('file.out', 'file.in', 'cp $SOURCE file.oout')
</programlisting>
<para>
(Note to Windows users: The POSIX &cp; command
copies the first file named on the command line
to the second file.
In our example, it copies the &file_in; file
to the &file_out; file.)
</para>
<para>
Now if we run &SCons; multiple on this example,
we see that it re-runs the &cp;
command every time:
</para>
<screen>
% <userinput>scons -Q</userinput>
cp file.in file.oout
% <userinput>scons -Q</userinput>
cp file.in file.oout
% <userinput>scons -Q</userinput>
cp file.in file.oout
</screen>
<para>
In this example,
the underlying cause is obvious:
we've intentionally misspelled the output file name
in the &cp; command,
so the command doesn't actually
build the &file_out; file that we've told &SCons; to expect.
But if the problem weren't obvious,
it would be helpful
to specify the &debug-explain; option
on the command line
to have &SCons; tell us very specifically
why it's decided to rebuild the target:
</para>
<screen>
% <userinput>scons -Q --debug=explain</userinput>
scons: building `file.out' because it doesn't exist
cp file.in file.oout
</screen>
<para>
If this had been a more complicated example
involving a lot of build output,
having &SCons; tell us that
it's trying to rebuild the target file
because it doesn't exist
would be an important clue
that something was wrong with
the command that we invoked to build it.
</para>
<para>
The &debug-explain; option also comes in handy
to help figure out what input file changed.
Given a simple configuration that builds
a program from three source files,
changing one of the source files
and rebuilding with the &debug-explain;
option shows very specifically
why &SCons; rebuilds the files that it does:
</para>
<screen>
% <userinput>scons -Q</userinput>
cc -c -o file1.o file1.c
cc -c -o file2.o file2.c
cc -c -o file3.o file3.c
cc -o prog file1.o file2.o file3.o
% <userinput>edit file2.c</userinput>
[CHANGE THE CONTENTS OF file2.c]
% <userinput>scons -Q --debug=explain</userinput>
scons: rebuilding `file2.o' because `file2.c' changed
cc -c -o file2.o file2.c
scons: rebuilding `prog' because `file2.o' changed
cc -o prog file1.o file2.o file3.o
</screen>
<para>
This becomes even more helpful
in identifying when a file is rebuilt
due to a change in an implicit dependency,
such as an incuded <filename>.h</filename> file.
If the <filename>file1.c</filename>
and <filename>file3.c</filename> files
in our example
both included a &hello_h; file,
then changing that included file
and re-running &SCons; with the &debug-explain; option
will pinpoint that it's the change to the included file
that starts the chain of rebuilds:
</para>
<screen>
% <userinput>scons -Q</userinput>
cc -I. -c -o file1.o file1.c
cc -I. -c -o file2.o file2.c
cc -I. -c -o file3.o file3.c
cc -o prog file1.o file2.o file3.o
% <userinput>edit hello.h</userinput>
[CHANGE THE CONTENTS OF hello.h]
% <userinput>scons -Q --debug=explain</userinput>
scons: rebuilding `file1.o' because `hello.h' changed
cc -I. -c -o file1.o file1.c
scons: rebuilding `file3.o' because `hello.h' changed
cc -I. -c -o file3.o file3.c
scons: rebuilding `prog' because:
`file1.o' changed
`file3.o' changed
cc -o prog file1.o file2.o file3.o
</screen>
</section>
|
