summaryrefslogtreecommitdiff
path: root/doc/user/actions.in
blob: 1ea5c49f47b6a999034da3697fe5cf386e1ae95c (plain)
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
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
<!--

  Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 The SCons Foundation

  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.

-->

<!--

=head1 Build actions

Cons supports several types of B<build actions> that can be performed
to construct one or more target files.  Usually, a build action is
a construction command, that is, a command-line string that invokes
an external command.  Cons can also execute Perl code embedded in a
command-line string, and even supports an experimental ability to build
a target file by executing a Perl code reference directly.

A build action is usually specified as the value of a construction
variable:

  $env = new cons(
	CCCOM         => '%CC %CFLAGS %_IFLAGS -c %< -o %>',
	LINKCOM       => '[perl] &link_executable("%>", "%<")',
	ARCOM         => sub { my($env, $target, @sources) = @_;
				 # code to create an archive
				}
  );

A build action may be associated directly with one or more target files
via the C<Command> method; see below.

=head2 Construction commands

A construction command goes through expansion of construction variables
and C<%-> pseudo-variables, as described above, to create the actual
command line that Cons will execute to generate the target file or
files.

After substitution occurs, strings of white space are converted into
single blanks, and leading and trailing white space is eliminated. It
is therefore currently not possible to introduce variable length white
space in strings passed into a command.

If a multi-line command string is provided, the commands are executed
sequentially. If any of the commands fails, then none of the rest are
executed, and the target is not marked as updated, i.e. a new signature is
not stored for the target.

Normally, if all the commands succeed, and return a zero status (or whatever
platform-specific indication of success is required), then a new signature
is stored for the target. If a command erroneously reports success even
after a failure, then Cons will assume that the target file created by that
command is accurate and up-to-date.

The first word of each command string, after expansion, is assumed to be an
executable command looked up on the C<PATH> environment variable (which is,
in turn, specified by the C<ENV> construction variable). If this command is
found on the path, then the target will depend upon it: the command will
therefore be automatically built, as necessary. It's possible to write
multi-part commands to some shells, separated by semi-colons. Only the first
command word will be depended upon, however, so if you write your command
strings this way, you must either explicitly set up a dependency (with the
C<Depends> method), or be sure that the command you are using is a system
command which is expected to be available. If it isn't available, you will,
of course, get an error.

Cons normally prints a command before executing it.  This behavior is
suppressed if the first character of the command is C<@>.  Note that
you may need to separate the C<@> from the command name or escape it to
prevent C<@cmd> from looking like an array to Perl quote operators that
perform interpolation:

  # The first command line is incorrect,
  # because "@cp" looks like an array
  # to the Perl qq// function.
  # Use the second form instead.
  Command $env 'foo', 'foo.in', qq(
	@cp %< tempfile
	@ cp tempfile %>
  );

If there are shell meta characters anywhere in the expanded command line,
such as C<E<lt>>, C<E<gt>>, quotes, or semi-colon, then the command
will actually be executed by invoking a shell. This means that a command
such as:

  cd foo

alone will typically fail, since there is no command C<cd> on the path. But
the command string:

  cd $<:d; tar cf $>:f $<:f

when expanded will still contain the shell meta character semi-colon, and a
shell will be invoked to interpret the command. Since C<cd> is interpreted
by this sub-shell, the command will execute as expected.

=head2 Perl expressions

If any command (even one within a multi-line command) begins with
C<[perl]>, the remainder of that command line will be evaluated by the
running Perl instead of being forked by the shell.  If an error occurs
in parsing the Perl code, or if the Perl expression returns 0 or undef,
the command will be considered to have failed.  For example, here is a
simple command which creates a file C<foo> directly from Perl:

  $env = new cons();
  Command $env 'foo',
    qq([perl] open(FOO,'>foo');print FOO "hi\\n"; close(FOO); 1);

Note that when the command is executed, you are in the same package as
when the F<Construct> or F<Conscript> file was read, so you can call
Perl functions you've defined in the same F<Construct> or F<Conscript>
file in which the C<Command> appears:

  $env = new cons();
  sub create_file {
	my $file = shift;
	open(FILE, ">$file");
	print FILE "hi\n";
	close(FILE);
	return 1;
  }
  Command $env 'foo', "[perl] &create_file('%>')";

The Perl string will be used to generate the signature for the derived
file, so if you change the string, the file will be rebuilt.  The contents
of any subroutines you call, however, are not part of the signature,
so if you modify a called subroutine such as C<create_file> above,
the target will I<not> be rebuilt.  Caveat user.

=head2 Perl code references [EXPERIMENTAL]

Cons supports the ability to create a derived file by directly executing
a Perl code reference.  This feature is considered EXPERIMENTAL and
subject to change in the future.

A code reference may either be a named subroutine referenced by the
usual C<\&> syntax:

  sub build_output {
	my($env, $target, @sources) = @_;
	print "build_output building $target\n";
	open(OUT, ">$target");
	foreach $src (@sources) {
	    if (! open(IN, "<$src")) {
		print STDERR "cannot open '$src': $!\n";
		return undef;
	    }
	    print OUT, <IN>;
	}
	close(OUT);
	return 1;
  }
  Command $env 'output', \&build_output;

or the code reference may be an anonymous subroutine:

  Command $env 'output', sub {
	my($env, $target, @sources) = @_;
	print "building $target\n";
	open(FILE, ">$target");
	print FILE "hello\n";
	close(FILE);
	return 1;
  };

To build the target file, the referenced subroutine is passed, in order:
the construction environment used to generate the target; the path
name of the target itself; and the path names of all the source files
necessary to build the target file.

The code reference is expected to generate the target file, of course,
but may manipulate the source and target files in any way it chooses.
The code reference must return a false value (C<undef> or C<0>) if
the build of the file failed.  Any true value indicates a successful
build of the target.

Building target files using code references is considered EXPERIMENTAL
due to the following current limitations:

=over 4

Cons does I<not> print anything to indicate the code reference is being
called to build the file.  The only way to give the user any indication
is to have the code reference explicitly print some sort of "building"
message, as in the above examples.

Cons does not generate any signatures for code references, so if the
code in the reference changes, the target will I<not> be rebuilt.

Cons has no public method to allow a code reference to extract
construction variables.  This would be good to allow generalization of
code references based on the current construction environment, but would
also complicate the problem of generating meaningful signatures for code
references.

=back

Support for building targets via code references has been released in
this version to encourage experimentation and the seeking of possible
solutions to the above limitations.

-->

  <para>

  &SCons; supports several types of &build_actions;
  that can be performed to build one or more target files.
  Usually, a &build_action; is a command-line string
  that invokes an external command.
  A build action can also be an external  command
  specified as a list of arguments,
  or even a Python function.

  </para>

  <para>

  Build action objects are created by the &Action; function.
  This function is, in fact, what &SCons; uses
  to interpret the &action;
  keyword argument when you call the &Builder; function.
  So the following line that creates a simple Builder:

  </para>

  <sconstruct>
    b = Builder(action = 'build < $SOURCE > $TARGET')
  </sconstruct>

  <para>

  Is equivalent to:

  </para>

  <sconstruct>
    b = Builder(action = Action('build < $SOURCE > $TARGET'))
  </sconstruct>

  <para>

  The advantage of using the &Action; function directly
  is that it can take a number of additional options
  to modify the action's behavior in many useful ways.

  </para>

  <section>
  <title>Command Strings as Actions</title>

    <section>
    <title>Suppressing Command-Line Printing</title>

    <para>

    XXX

    </para>

    </section>

    <section>
    <title>Ignoring Exit Status</title>

    <para>

    XXX

    </para>

    </section>

  </section>

  <section>
  <title>Argument Lists as Actions</title>

  <para>

  XXX

  </para>

  </section>

  <section>
  <title>Python Functions as Actions</title>

  <para>

  XXX

  </para>

  </section>

  <section>
  <title>Modifying How an Action is Printed</title>

    <section>
    <title>XXX:  the &strfunction; keyword argument</title>

    <para>

    XXX

    </para>

    </section>

    <section>
    <title>XXX:  the &cmdstr; keyword argument</title>

    <para>

    XXX

    </para>

    </section>

  </section>

  <section>
  <title>Making an Action Depend on Variable Contents:  the &varlist; keyword argument</title>

  <para>

  XXX

  </para>

  </section>

  <section>
  <title>chdir=1</title>

  <para>

  XXX

  </para>

  </section>

  <section>
  <title>Batch Building of Multiple Targets from Separate Sources:  the &batch_key; keyword argument</title>

  <para>

  XXX

  </para>

  </section>

  <section>
  <title>Manipulating the Exit Status of an Action:  the &exitstatfunc; keyword argument</title>

  <para>

  XXX

  </para>

  </section>

  <!--

  ???

  <section>
  <title>presub=</title>

  <para>

  XXX

  </para>

  </section>

  -->