...

The first line is what creates a static library object containing all the information necessary to build the library at a later point. Notice we use the libEnv variable. This is one of the copies made of the base environment. This copy should be used for any libraries to be compiled. It should NEVER be used for creating an application. If this rule is violated it will cause errors in other packages that will be hard to track back down to this source.

Wiki MarkupThe StaticLibrary function call takes two arguments. The first argument specifies the name that should be given to the library. This name should not include any prefixes/suffixes that are platform specific. SCons will take care of adding those automatically. This example on Unix based systems would create a library named {{libmyLib.a}}. The second argument to SCons is a list of files to be compiled into the library. In this case we specify that the files to be included are in the src directory, relative to the top directory of the package, and are named \ *.cxx (anything ending with .cxx). Should only a single file be needed for the compilation of that library we can either specify a single file to the listFiles function call {{listFiles('src/myLib.cxx')}} or we can simply skip the use of listFiles() call and replace the entire listFiles function call with \ ['src/myLib.cxx'\].

The second line will register our objects at the top level to be compiled when appropriate. This is not a standard SCons ability but custom extension to SCons. Several things to note are that we use the progEnv copy of the environment to register objects even if the objects are libraries. This is a convention we strong suggest you abide by.

Wiki MarkupThe arguments used by the Tool() call are as follows. The first argument is the name of the tool to be called. Without going into too much detail at this point, this argument needs to always be specified 'regsiterObjects'. The second argument is the name of the package. The third argument is a list of library objects to be registered for this package. These can be shared or static. The name of the variable used is the same as the one used to store the library object returned by libEnv.StaticLibrary() call on the previous line. The next argument is a list of include files to be registered. These are *ONLY* the public include files necessary to use the libraries that are going to be registered. Since we only need a single header file to be registered we specify it with {{\['myPackage/myLib.h'\]}}. If a list of header files, such as \ *.h, needed to be specified we could use the listFiles() call again. Other arguments can be specified as well. A complete list is provided in a later section.

Simple Shared library

The steps to create a shared library are similar to those for a static library. The code looks as follows.

...

myApp = progEnv.Program('myProgram', ['src/myProgram.cxx'])

Wiki MarkupWe use the progEnv copy of the base environment to create a program objection. The copy of the environment for creating libraries should *NEVER* be used for this task. It will generate problems in other packages and will be very difficult to trace back. The arguments provided to the progEnv.Program() call are similar to those for libraries. The first argument is the name of the executable making sure to exclude and platform specific prefixes or suffixes. On Windows SCons will create a program called myProgram.exe. The second argument is a list of source code files to compile the program. All three methods described in the previous two sections are valid here as well (listFiles(), \ ['single file'\], or \ ['list', 'of', 'files'\]).

Just like in the previous two sections, we need to register the program object with the top level before it can be used. Assuming the static and shared libraries from before still exist and we want to add this program to the registration call we would modify the registration line as follows

...

OS specific conditions

If you wish to perform functions on certain platforms only you can use regular python conditionals around the functions.
For example to define the TRAP_FPE macro only on Linux platforms we would append:

...

When SCons is performing the build process it will put files in the following subdirectories that are located in the same directory as the SConstruct file:

• Wiki Markupinclude/\include/[packageName\] - all the globally shared header files for \ [packageName\]unmigrated-wiki-markup
• bin/\[variant\] - all the binaries for the variant. A variant specifies the OS and compile options such as debug or optimized.
• Wiki Markuplib/\[variant\] - all the libraries for the variant. This variant string is the same as above
• Wiki Markuppfiles/\[packageName\] - all the pfiles for \ [packageName\]

Other such output directories will be created in the future and they will follow the same convention. If the contents of the directory is dependent on the OS or the compile options, it will include the variant sub directory. If it is independent of such changes it will not include that directory.