Internally, SCons represents all of the files and directories it knows about as Nodes. These internal objects (not object files) can be used in a variety of ways to make your SConscript files portable and easy to read.
All builder methods return a list of
Node objects that identify the
target file or files that will be built.
These returned Nodes can be passed
as arguments to other builder methods.
For example, suppose that we want to build
the two object files that make up a program with different options.
This would mean calling the
builder once for each object file,
specifying the desired options:
Object('hello.c', CCFLAGS='-DHELLO') Object('goodbye.c', CCFLAGS='-DGOODBYE')
One way to combine these object files
into the resulting program
would be to call the
builder with the names of the object files
listed as sources:
Object('hello.c', CCFLAGS='-DHELLO') Object('goodbye.c', CCFLAGS='-DGOODBYE') Program(['hello.o', 'goodbye.o'])
The problem with specifying the names as strings is that our SConstruct file is no longer portable across operating systems. It won't, for example, work on Windows because the object files there would be named hello.obj and goodbye.obj, not hello.o and goodbye.o.
A better solution is to assign the lists of targets
returned by the calls to the
Object builder to variables,
which we can then concatenate in our
call to the
hello_list = Object('hello.c', CCFLAGS='-DHELLO') goodbye_list = Object('goodbye.c', CCFLAGS='-DGOODBYE') Program(hello_list + goodbye_list)
This makes our SConstruct file portable again, the build output on Linux looking like:
% scons -Q cc -o goodbye.o -c -DGOODBYE goodbye.c cc -o hello.o -c -DHELLO hello.c cc -o hello hello.o goodbye.o
And on Windows:
C:\>scons -Q cl /Fogoodbye.obj /c goodbye.c -DGOODBYE cl /Fohello.obj /c hello.c -DHELLO link /nologo /OUT:hello.exe hello.obj goodbye.obj embedManifestExeCheck(target, source, env)
We'll see examples of using the list of nodes returned by builder methods throughout the rest of this guide.