ImportProject

Returns:  The project class instance.

• The project class contains everything known about the project (currently limited to the include directory and the libraries, but may expand in the future).  It is the backbone of all that follows.
• This returned value can be used to access the ImportLibraries, ImportLibrary, UseLibraries and UseLibrary for that project.
• It also serves as the ‘constructor’, although (and maybe this was a mistake) one can also import libraries with it.  (That was so you could kind of do everything in one step.)

ImportLibraries

Returns:  A dictionary of all the known libraries that have been imported

• The specified list of libraries (if any) is added to the known list.

ImportLibrary

Returns: A dictionary of all the known libraries that have been imported

• This behaves exactly as ImportLibraries and is provided purely as a bow to symmetry.

UseLibraries

Returns:  A list of file specs that can be used directly in the builder LIBS = ...

• The specified list libraries is not imported, so this is purely good for local use.

UseLibrary

Returns: A single library file spec that can be used directly in the builder

• This library file spec is not imported, so this is purely good for local use.

The UseLibrary/UseLibraries can be thought of as a translation of generic library names into library file specs, i.e. something that can be used in a builders LIB = argument.

These methods work from either

• The env

  • The env maintains a dictionary of named projects (the name is provided as an argument to ImportProject, if not provided, the local project is assumed). Effectively this call just looks up the named project in this dictionary to locate its class instance. (If it doesn’t find it, a new named project is created).
  • The env provides one the ability to communicate information from one Sconscript to the other, using the project name as a locator
• The project class returned from ImportProject
  • No name is required, since the name of a project is purely for use in the env.

Perhaps for symmetry, there should be a prj.ImportInclude, since the currently the only way to access the include is via an ImportProject call….

EXAMPLES

1. prj = env.ImportProject ()
   since no name is provided, the local project is targeted
2. core = env.ImportProject (name = ‘CORE’)
   access the project named core.  Since this one is pre-initialized, this is an access, not a creation

3. csc = env.ImportProject (name = ‘CSC’)
   If the project was previously created, it is just accessed.
   If not, the project is created, using the current project as a template, i.e. it assumes the same include and library directory layout, as it does the library prefix and suffix.  If these need customizing the full call is

   env.ImportProject (name = <name>,  root = <root_directory>, incdir = <include_directory>, (can be absolute or relative to root, eg ‘inc’), libdir = <library_directory>, (can be absolute or relative to root, ‘iib’), pkgdir = <package_directory>, (this is not too useful), libprefix = <library_prefix> , (eg ‘lib’), libsuffix = <library_suffix>, (eg ‘.so’)

   Here’s the call I use to initialize the ‘CORE’ project


   env.ImportProject (name = 'CORE', incdir = paths.inc_core, libdir = paths.lib)

   If one had a need or desire to tailor each individual package, then the ‘pkgdir’ would be useful.
   Effectively one could create a ‘Project’ for each package.

The pkgdir can be a list representing the subdirectory path, e.g., pkgdir=(x,y,z) gets used as x/y/z.