summaryrefslogtreecommitdiffstats
path: root/doc/user/simple.sgml
blob: 8cafe2d87760f0622c10bb852b7555c99185299f (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
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
<!--

  Copyright (c) 2001, 2002, 2003 Steven Knight

  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.

-->

<!--

=head2 Perl scripts

Cons is Perl-based. That is, Cons scripts F<Conscript> and F<Construct>
files, the equivalent to F<Makefile> or F<makefile> are all written in
Perl. This provides an immediate benefit: the language for writing scripts
is a familiar one. Even if you don't happen to be a Perl programmer, it
helps to know that Perl is basically just a simple declarative language,
with a well-defined flow of control, and familiar semantics. It has
variables that behave basically the way you would expect them to,
subroutines, flow of control, and so on. There is no special syntax
introduced for Cons. The use of Perl as a scripting language simplifies
the task of expressing the appropriate solution to the often complex
requirements of a build.

-->

 <para>

 Here's how to build the famous "Hello, World!" example using &SCons;.

 </para>

 <programlisting>
    int
    main()
    {
        printf("Hello, world!\n");
    }
 </programlisting>

 <para>

 Enter the following into a file name &SConstruct;:

 </para>

 <programlisting>
    env = Environment()
    env.Program('hello.c')
 </programlisting>

 <para>

 That's it.  Now run the &scons; command to build the program.
 On a POSIX-compliant system like Linux or UNIX,
 you'll see something like:

 </para>

 <literallayout>
    % <userinput>scons</userinput>
    cc -c hello.c -o hello.o
    cc -o hello hello.o
 </literallayout>

 <para>

 On a Windows system with the Microsoft Visual C++ compiler,
 you'll see something like:

 </para>

 <literallayout>
    C:\><userinput>scons</userinput>
    cl /Fohello.obj hello.c
    link /Fohello.exe hello.obj
 </literallayout>

 <para>

 First, notice that you only need
 to specify the name of the source file,
 and that &SCons; deduces the names of
 the object and executable files
 correctly from the source file.

 </para>

 <para>

 Second, notice that the same input &SConstruct; file
 without any changes,
 generates the correct output file names on both systems:
 <filename>hello.o</filename> and <filename>hello</filename>
 on POSIX systems,
 <filename>hello.obj</filename> and <filename>hello.exe</filename>
 on Windows systems.
 This is a simple example of how easy it is to
 use &SCons; to write portable software builds.

 </para>

 <para>

 (Note that we won't provide duplicate side-by-side
 POSIX and Windows output for the 
 rest of the examples in this guide;
 just keep in mind that, unless otherwise specified,
 any of the examples should work equally well on both types of systems.)

 </para>

 <section>
 <title>The &SConstruct; File</title>

   <para>

   If you're used to build systems like &Make;
   you've already figured out that the &SConstruct; file
   is the &SCons; equivalent of a &Makefile;.
   That is, the &SConstruct; file is the input file
   that &SCons; reads to control the build.

   </para>

   <para>

   What may not be obvious, though, is that
   there's an important difference between
   an &SConstruct; file and a &Makefile:
   the &SConstruct; file is actually a Python script.
   If you're not already familiar with Python, don't worry;
   Python is extremely easy to learn,
   and this User's Guide will introduce you step-by-step
   to the relatively small amount of Python you'll
   neede to know to be able to use &SCons; effectively.

   </para>

   <para>

   One aspect of using Python as the
   scripting language is that you can put comments
   in your &SConstruct; file using Python's commenting convention;
   that is, everything between a '#' and the end of the line
   will be ignored:

   </para>

   <programlisting>
      env = Environment()    # Create an environment.
      # Arrange to build the "hello" program.
      env.Program('hello.c')
   </programlisting>

   <para>

   You'll see throughout the remainder of this Guide
   that being able to use the power of a
   real scripting language
   can greatly simplify the solutions
   to complex requirements of real-world builds.

   </para>

 </section>

 <section>
 <title>Compiling Multiple Source Files</title>

   <para>

   It's more common, of course,
   that you'll need to build a program from
   not just one, but many input source files.
   To do this, you need to put the
   source files in a Python list
   (enclosed in square brackets),
   and slide that list over to to the right
   to make room for the output program file name.
   For example:

   </para>

   <programlisting>
      env = Environment()
      env.Program('program', ['main.c', 'file1.c', 'file2.'])
   </programlisting>

   <para>

   (&SCons; puts the output file name to the left
   of the source file names
   so that the order mimics that of an
   assignment statement:  "program = source files".)

   </para>

   <para>

   A build of the above example would look:

   </para>

   <literallayout>
      % <userinput>scons</userinput>
      cc -c file1.c -o file1.o
      cc -c file2.c -o file2.o
      cc -c main.c -o main.o
      cc -o program main.o file1.o file2.o
   </literallayout>

   <!--

   XXX DO WE NEED WINDOWS EXAMPLE OUTPUT HERE?

   </para>

   Or on Windows:

   </para>

   <literallayout>
      C:\><userinput>scons</userinput>
      cl /Fofile1.obj file1.c
      cl /Fofile2.obj file2.c
      cl /Fomain.obj main.c
      link /Foprogram.exe main.obj file1.obj file2.obj
   </literallayout>

   -->

 </section>

 <section>
 <title>Keeping &SConstruct; Files Easy to Read</title>

   <para>

   One minor drawback to the use of a Python list
   for source files is that 
   each file name must be enclosed in quotes
   (either single quotes or double quotes).
   This can get cumbersome and difficult to read
   when the list of file names is long.
   Fortunately, there are a number of things
   we can do to make sure that
   the &SConstruct; file stays easy to read.

   </para>

   <para>

   To make long lists of file names
   easier to deal with, &SCons; provides a
   &Split; function
   that takes a quoted list of file names,
   with the names separated by spaces or other white-space characters,
   and turns it into a list of separate file names.
   Using the &Split; function turns the
   previous example into:

   </para>

   <programlisting>
      env = Environment()
      env.Program('program', Split('main.c file1.c file2.'))
   </programlisting>

   <para>

   Putting the call to the &Split; function
   inside the <function>env.Program</function> call
   can also be a little unwieldy.
   A more readable alternative is to
   assign the output from the &Split; call
   to a variable name,
   and then use the variable when calling the
   <function>env.Program</function> function:

   </para>

   <programlisting>
      env = Environment()
      list = Split('main.c file1.c file2.')
      env.Program('program', list)
   </programlisting>

   <para>

   Lastly, the &Split; function
   doesn't care how much white space separates
   the file names in the quoted string.
   This allows you to create lists of file
   names that span multiple lines,
   which often makes for easier editing:

   </para>

   <programlisting>
      env = Environment()
      list = Split('main.c
                    file1.c
                    file2.c')
      env.Program('program', list)
   </programlisting>

 </section>

 <section>
 <title>Keyword Arguments</title>

   <para>

   &SCons; also allows you to identify
   the output file and input source files
   by Python keyword arguments.
   The output file is known as the
   <emphasis>target</emphasis>,
   and the source file(s) are known (logically enough) as the
   <emphasis>source</emphasis>.
   The Python syntax for this is:

   </para>

   <programlisting>
      env = Environment()
      list = Split('main.c file1.c file2.')
      env.Program(target = 'program', source = list)
   </programlisting>

   <para>

   Whether or not you choose to use keyword arguments
   to identify the target and source files
   is purely a personal choice.

   </para>

 </section>

 <section>
 <title>Compiling Multiple Programs</title>

   <para>

   In order to compile multiple programs
   within the same &SConstruct; file,
   simply call <function>env.Program</function>
   multiple times,
   once for each program you need to build:

   </para>

   <programlisting>
      env = Environment()
      env.Program('foo.c')
      env.Program('bar', ['bar1.c', 'bar2.c'])
   </programlisting>

   <para>

   &SCons; would then build the programs as follows:

   </para>

   <literallayout>
      % <userinput>scons</userinput>
      cc -c bar1.c -o bar1.o
      cc -c bar2.c -o bar2.o
      cc -o bar bar1.o bar2.o
      cc -c foo.c -o foo.o
      cc -o foo foo.o
   </literallayout>

 </section>

 <section>
 <title>Sharing Source Files Between Multiple Programs</title>

   <para>

   XXX

   </para>

   <programlisting>
      common = ['common1.c', 'common2.c']
      env = Environment()
      env.Program(['foo.c'] + common)
      env.Program('bar', ['bar1.c', 'bar2.c'] + common)
   </programlisting>

   <literallayout>
      % <userinput>scons</userinput>
      cc -c bar1.c -o bar1.o
      cc -c bar2.c -o bar2.o
      cc -c common1.c -o common1.o
      cc -c common2.c -o common2.o
      cc -o bar bar1.o bar2.o common1.o common2.o
      cc -c foo.c -o foo.o
      cc -o foo foo.o common1.o common2.o
   </literallayout>

 </section>