5 Permission is hereby granted, free of charge, to any person obtaining
6 a copy of this software and associated documentation files (the
7 "Software"), to deal in the Software without restriction, including
8 without limitation the rights to use, copy, modify, merge, publish,
9 distribute, sublicense, and/or sell copies of the Software, and to
10 permit persons to whom the Software is furnished to do so, subject to
11 the following conditions:
13 The above copyright notice and this permission notice shall be included
14 in all copies or substantial portions of the Software.
16 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
17 KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
18 WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
19 NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
20 LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
21 OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
22 WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
30 Cons supports several types of B<build actions> that can be performed
31 to construct one or more target files. Usually, a build action is
32 a construction command, that is, a command-line string that invokes
33 an external command. Cons can also execute Perl code embedded in a
34 command-line string, and even supports an experimental ability to build
35 a target file by executing a Perl code reference directly.
37 A build action is usually specified as the value of a construction
41 CCCOM => '%CC %CFLAGS %_IFLAGS -c %< -o %>',
42 LINKCOM => '[perl] &link_executable("%>", "%<")',
43 ARCOM => sub { my($env, $target, @sources) = @_;
44 # code to create an archive
48 A build action may be associated directly with one or more target files
49 via the C<Command> method; see below.
51 =head2 Construction commands
53 A construction command goes through expansion of construction variables
54 and C<%-> pseudo-variables, as described above, to create the actual
55 command line that Cons will execute to generate the target file or
58 After substitution occurs, strings of white space are converted into
59 single blanks, and leading and trailing white space is eliminated. It
60 is therefore currently not possible to introduce variable length white
61 space in strings passed into a command.
63 If a multi-line command string is provided, the commands are executed
64 sequentially. If any of the commands fails, then none of the rest are
65 executed, and the target is not marked as updated, i.e. a new signature is
66 not stored for the target.
68 Normally, if all the commands succeed, and return a zero status (or whatever
69 platform-specific indication of success is required), then a new signature
70 is stored for the target. If a command erroneously reports success even
71 after a failure, then Cons will assume that the target file created by that
72 command is accurate and up-to-date.
74 The first word of each command string, after expansion, is assumed to be an
75 executable command looked up on the C<PATH> environment variable (which is,
76 in turn, specified by the C<ENV> construction variable). If this command is
77 found on the path, then the target will depend upon it: the command will
78 therefore be automatically built, as necessary. It's possible to write
79 multi-part commands to some shells, separated by semi-colons. Only the first
80 command word will be depended upon, however, so if you write your command
81 strings this way, you must either explicitly set up a dependency (with the
82 C<Depends> method), or be sure that the command you are using is a system
83 command which is expected to be available. If it isn't available, you will,
84 of course, get an error.
86 Cons normally prints a command before executing it. This behavior is
87 suppressed if the first character of the command is C<@>. Note that
88 you may need to separate the C<@> from the command name or escape it to
89 prevent C<@cmd> from looking like an array to Perl quote operators that
90 perform interpolation:
92 # The first command line is incorrect,
93 # because "@cp" looks like an array
94 # to the Perl qq// function.
95 # Use the second form instead.
96 Command $env 'foo', 'foo.in', qq(
101 If there are shell meta characters anywhere in the expanded command line,
102 such as C<E<lt>>, C<E<gt>>, quotes, or semi-colon, then the command
103 will actually be executed by invoking a shell. This means that a command
108 alone will typically fail, since there is no command C<cd> on the path. But
111 cd $<:d; tar cf $>:f $<:f
113 when expanded will still contain the shell meta character semi-colon, and a
114 shell will be invoked to interpret the command. Since C<cd> is interpreted
115 by this sub-shell, the command will execute as expected.
117 =head2 Perl expressions
119 If any command (even one within a multi-line command) begins with
120 C<[perl]>, the remainder of that command line will be evaluated by the
121 running Perl instead of being forked by the shell. If an error occurs
122 in parsing the Perl code, or if the Perl expression returns 0 or undef,
123 the command will be considered to have failed. For example, here is a
124 simple command which creates a file C<foo> directly from Perl:
128 qq([perl] open(FOO,'>foo');print FOO "hi\\n"; close(FOO); 1);
130 Note that when the command is executed, you are in the same package as
131 when the F<Construct> or F<Conscript> file was read, so you can call
132 Perl functions you've defined in the same F<Construct> or F<Conscript>
133 file in which the C<Command> appears:
138 open(FILE, ">$file");
143 Command $env 'foo', "[perl] &create_file('%>')";
145 The Perl string will be used to generate the signature for the derived
146 file, so if you change the string, the file will be rebuilt. The contents
147 of any subroutines you call, however, are not part of the signature,
148 so if you modify a called subroutine such as C<create_file> above,
149 the target will I<not> be rebuilt. Caveat user.
151 =head2 Perl code references [EXPERIMENTAL]
153 Cons supports the ability to create a derived file by directly executing
154 a Perl code reference. This feature is considered EXPERIMENTAL and
155 subject to change in the future.
157 A code reference may either be a named subroutine referenced by the
161 my($env, $target, @sources) = @_;
162 print "build_output building $target\n";
163 open(OUT, ">$target");
164 foreach $src (@sources) {
165 if (! open(IN, "<$src")) {
166 print STDERR "cannot open '$src': $!\n";
174 Command $env 'output', \&build_output;
176 or the code reference may be an anonymous subroutine:
178 Command $env 'output', sub {
179 my($env, $target, @sources) = @_;
180 print "building $target\n";
181 open(FILE, ">$target");
182 print FILE "hello\n";
187 To build the target file, the referenced subroutine is passed, in order:
188 the construction environment used to generate the target; the path
189 name of the target itself; and the path names of all the source files
190 necessary to build the target file.
192 The code reference is expected to generate the target file, of course,
193 but may manipulate the source and target files in any way it chooses.
194 The code reference must return a false value (C<undef> or C<0>) if
195 the build of the file failed. Any true value indicates a successful
198 Building target files using code references is considered EXPERIMENTAL
199 due to the following current limitations:
203 Cons does I<not> print anything to indicate the code reference is being
204 called to build the file. The only way to give the user any indication
205 is to have the code reference explicitly print some sort of "building"
206 message, as in the above examples.
208 Cons does not generate any signatures for code references, so if the
209 code in the reference changes, the target will I<not> be rebuilt.
211 Cons has no public method to allow a code reference to extract
212 construction variables. This would be good to allow generalization of
213 code references based on the current construction environment, but would
214 also complicate the problem of generating meaningful signatures for code
219 Support for building targets via code references has been released in
220 this version to encourage experimentation and the seeking of possible
221 solutions to the above limitations.
227 &SCons; supports several types of &build_actions;
228 that can be performed to build one or more target files.
229 Usually, a &build_action; is a command-line string
230 that invokes an external command.
231 A build action can also be an external command
232 specified as a list of arguments,
233 or even a Python function.
239 Build action objects are created by the &Action; function.
240 This function is, in fact, what &SCons; uses
241 to interpret the &action;
242 keyword argument when you call the &Builder; function.
243 So the following line that creates a simple Builder:
248 b = Builder(action = 'build < $SOURCE > $TARGET')
258 b = Builder(action = Action('build < $SOURCE > $TARGET'))
263 The advantage of using the &Action; function directly
264 is that it can take a number of additional options
265 to modify the action's behavior in many useful ways.
270 <title>Command Strings as Actions</title>
273 <title>Suppressing Command-Line Printing</title>
284 <title>Ignoring Exit Status</title>
297 <title>Argument Lists as Actions</title>
308 <title>Python Functions as Actions</title>
319 <title>Modifying How an Action is Printed</title>
322 <title>XXX: the &strfunction; keyword argument</title>
333 <title>XXX: the &cmdstr; keyword argument</title>
346 <title>Making an Action Depend on Variable Contents: the &varlist; keyword argument</title>
357 <title>chdir=1</title>
368 <title>Batch Building of Multiple Targets from Separate Sources: the &batch_key; keyword argument</title>
379 <title>Manipulating the Exit Status of an Action: the &exitstatfunc; keyword argument</title>
394 <title>presub=</title>