Package mbuild

source code

This is mbuild: a simple portable dependence-based build-system written in python.

mbuild is a python-based build system very similar to scons with some philosophical features of make. mbuild exposes the scan and build phases allowing them to be repeated as necessary. Multiple DAGs can be built, one during each scan phase.

Conceptually there are 3 major components to mbuild:

• The environment env_t
• The directed acyclic graph dag_t
• The work queue work_queue_t

Using the environment env_t you customize your build configuration and construct names for your source files, object files, executables, etc. The environment contains builder methods that create plan_t objects. There are builders for C, C++, static and dynamic libraries, assembly files and linking programs. The environment and builders support string substitution.

The plan_t objects are passed to the dag_t which stores the dependences that order execution. The plan_t objects describe work that needs to be done. Plans typically contain a command line strings (with all substitutions done), but can also be python functions that will be executed during the build.

Using the plan_t objects, the dag_t creates command_t objects that are passed to the work_queue_t to ultimately build the target or targets.

Your build file can have multiple environments, DAGS and work queues.

Using the environment dictionary

You can bind or augmenting environment variables from the command line. For example, one can say build_cpu=ia32 on an x86-64 system to change the default compilation behavior. Similarly, one can say CXXFLAGS+=-g to add the -g flag to the existing CXXFLAGS variable.

Dynamic substitution is also used. Patterns of the form %(string)s will substitute string dynamically before it is used. The expansion can happen directly from the environment and is recursive. The expansion can also use dictionaries that are variables in the environment. A dictionary in the environment is really a tuple of the key-variable and the dictionary itself.

For example:

   env['opt_flag'] = ( 'opt', {'noopt':'',
                               '0':'%(OPTOPT)s0',
                               '1':'%(OPTOPT)s1',
                               '2':'%(OPTOPT)s2',
                               '3':'%(OPTOPT)s3',
                               '4':'%(OPTOPT)s4'} )

   env['OPTOPT'] = ( 'compiler', { 'gnu':'-O',
                                   'ms':'/O'})


   env['CXXFLAGS'] += ' %(opt_flag)s'

The OPTOPT variable depends on env['compiler']. If env['compiler']='gnu' then env['OPTOPT'] expands to -O. If env['compiler']='ms' then env['OPTOPT'] expands to /O.

If the opt variable is set "opt=3" on the command line, or equivalently if env['opt']='3' is set in the script, then if the env['compiler']='gnu' in the environment at the time of expansion, then the flag in the CXXFLAGS will be -O3. If env['compiler']='ms' at the time of expansion, then the optimiation flag would be /O3. If opt=noopt (on the command line) then there will be no optimization flag in the CXXFLAGS.

Introspection

The command_t that are executed during the build have their output (stdout/stderr) stored in the dag_t. After a build it is possible to collect the commands using the dag_t.results function and analyze the output. This is very handy for test and validation suites.