mozbuild.backend package


mozbuild.backend.base module

class mozbuild.backend.base.BuildBackend(environment)

Bases: mach.mixin.logging.LoggingMixin

Abstract base class for build backends.

A build backend is merely a consumer of the build configuration (the output of the frontend processing). It does something with said data. What exactly is the discretion of the specific implementation.

build(config, output, jobs, verbose, what=None)

Called when ‘mach build’ is executed.

This should return the status value of a subprocess, where 0 denotes success and any other value is an error code. A return value of None indicates that the default ‘make -f’ should run.


Consume a stream of TreeMetadata instances.

This is the main method of the interface. This is what takes the frontend output and does something with it.

Child classes are not expected to implement this method. Instead, the base class consumes objects and calls methods (possibly) implemented by child classes.


Called when consume() has completed handling all objects.


Consumes an individual TreeMetadata instance.

This is the main method used by child classes to react to build metadata.

post_build(config, output, jobs, verbose, status)

Called late during ‘mach build’ execution, after build(…) has finished.

status is the status value returned from build(…).

In the case where build returns None, this is called after the default make command has completed, with the status of that command.

This should return the status value from build(…), or the status value of a subprocess, where 0 denotes success and any other value is an error code.

If an exception is raised, |mach build| will fail with a non-zero exit code.


A HybridBackend is the combination of one or more PartialBackends with a non-partial BuildBackend.

Build configuration objects are passed to each backend, stopping at the first of them that declares having handled them.

class mozbuild.backend.base.PartialBackend(environment)

Bases: mozbuild.backend.base.BuildBackend

A PartialBackend is a BuildBackend declaring that its consume_object method may not handle all build configuration objects it’s passed, and that it’s fine.

mozbuild.backend.cargo_build_defs module

mozbuild.backend.common module

class mozbuild.backend.common.BinariesCollection

Bases: object

Tracks state of binaries produced by the build.

class mozbuild.backend.common.CommonBackend(environment)

Bases: mozbuild.backend.base.BuildBackend

Holds logic common to all build backends.

localized_path(relativesrcdir, filename)

Return the localized path for a file.

Given relativesrcdir, a path relative to the topsrcdir, return a path to filename from the current locale as specified by MOZ_UI_LOCALE, using L10NBASEDIR as the parent directory for non-en-US locales.

class mozbuild.backend.common.XPIDLManager(config)

Bases: object

Helps manage XPCOM IDLs in the context of the build system.

class Module

Bases: object


Return an iterator of stems of the managed IDL files.

The stem of an IDL file is the basename of the file with no .idl extension.

Links an XPIDL module with with this instance.

mozbuild.backend.configenvironment module

class mozbuild.backend.configenvironment.BuildConfig

Bases: object

Represents the output of configure.

classmethod from_config_status(path)

Create an instance from a config.status file.

class mozbuild.backend.configenvironment.ConfigEnvironment(topsrcdir, topobjdir, defines=None, non_global_defines=None, substs=None, source=None, mozconfig=None)

Bases: object

Perform actions associated with a configured but bare objdir.

The purpose of this class is to preprocess files from the source directory and output results in the object directory.

There are two types of files: config files and config headers, each treated through a different member function.

Creating a ConfigEnvironment requires a few arguments:
  • topsrcdir and topobjdir are, respectively, the top source and the top object directory.
  • defines is a dict filled from AC_DEFINE and AC_DEFINE_UNQUOTED in autoconf.
  • non_global_defines are a list of names appearing in defines above that are not meant to be exported in ACDEFINES (see below)
  • substs is a dict filled from AC_SUBST in autoconf.

ConfigEnvironment automatically defines one additional substs variable from all the defines not appearing in non_global_defines:

  • ACDEFINES contains the defines in the form -DNAME=VALUE, for use on preprocessor command lines. The order in which defines were given when creating the ConfigEnvironment is preserved.
and two other additional subst variables from all the other substs:
  • ALLSUBSTS contains the substs in the form NAME = VALUE, in sorted order, for use in It includes ACDEFINES Only substs with a VALUE are included, such that the resulting file doesn’t change when new empty substs are added. This results in less invalidation of build dependencies in the case of
  • ALLEMPTYSUBSTS contains the substs with an empty value, in the form NAME =.

ConfigEnvironment expects a “top_srcdir” subst to be set with the top source directory, in msys format on windows. It is used to derive a “srcdir” subst when treating config files. It can either be an absolute path or a path relative to the topobjdir.


A specialized version of the memoize decorator that works for class instance properties.

static from_config_status(path)
exception mozbuild.backend.configenvironment.ConfigStatusFailure

Bases: exceptions.Exception

Error loading config.status

class mozbuild.backend.configenvironment.PartialConfigDict(config_statusd, typ, environ_override=False)

Bases: object

Facilitates mapping the config.statusd defines & substs with dict-like access.

This allows a buildconfig client to use buildconfig.defines[‘FOO’] (and similar for substs), where the value of FOO is delay-loaded until it is needed.

get(key, default=None)
class mozbuild.backend.configenvironment.PartialConfigEnvironment(topobjdir)

Bases: object

Allows access to individual config.status items via config.statusd/* files.

This class is similar to the full ConfigEnvironment, which uses config.status, except this allows access and tracks dependencies to individual configure values. It is intended to be used during the build process to handle things like GENERATED_FILES, CONFIGURE_DEFINE_FILES, and anything else that may need to access specific substs or defines.

Creating a PartialConfigEnvironment requires only the topobjdir, which is needed to distinguish between the top-level environment and the js/src environment.

The PartialConfigEnvironment automatically defines one additional subst variable from all the defines not appearing in non_global_defines:

  • ACDEFINES contains the defines in the form -DNAME=VALUE, for use on preprocessor command lines. The order in which defines were given when creating the ConfigEnvironment is preserved.
and one additional define from all the defines as a dictionary:
  • ALLDEFINES contains all of the global defines as a dictionary. This is

intended to be used instead of the defines structure from config.status so that scripts can depend directly on its value.


mozbuild.backend.cpp_eclipse module

class mozbuild.backend.cpp_eclipse.CppEclipseBackend(environment)

Bases: mozbuild.backend.common.CommonBackend

Backend that generates Cpp Eclipse project files.

static get_workspace_path(topsrcdir, topobjdir)

mozbuild.backend.fastermake module

class mozbuild.backend.fastermake.FasterMakeBackend(environment)

Bases: mozbuild.backend.common.CommonBackend, mozbuild.backend.base.PartialBackend


mozbuild.backend.mach_commands module

class mozbuild.backend.mach_commands.MachCommands(context)

Bases: mozbuild.base.MachCommandBase

eclipse(ide, args)

mozbuild.backend.recursivemake module

class mozbuild.backend.recursivemake.BackendMakeFile(srcdir, objdir, environment, topsrcdir, topobjdir, dry_run)

Bases: object

Represents a generated file.

This is both a wrapper around a file handle as well as a container that holds accumulated state.

It’s worth taking a moment to explain the make dependencies. The generated as well as the (if it exists) are in the GLOBAL_DEPS list. This means that if one of them changes, all targets in that Makefile are invalidated. also depends on all of its input files.

It’s worth considering the effect of file mtimes on build behavior.

Since we perform an “all or none” traversal of files (the whole tree is scanned as opposed to individual files), if we were to blindly write files, the net effect of updating a single mozbuild file in the tree is all files have new mtimes. This would in turn invalidate all make targets across the whole tree! This would effectively undermine incremental builds as any mozbuild change would cause the entire tree to rebuild!

The solution is to not update the mtimes of files unless they actually change. We use FileAvoidWrite to accomplish this.

class mozbuild.backend.recursivemake.RecursiveMakeBackend(environment)

Bases: mozbuild.backend.common.CommonBackend

Backend that integrates with the existing recursive make build system.

This backend facilitates the transition from to files.

This backend performs -> Makefile conversion. It also writes out .mk files containing content derived from files. Both are consumed by the recursive make builder.

This backend may eventually evolve to write out non-recursive make files. However, as long as there are files in the tree, we are tied to recursive make and thus will need this backend.

class Substitution

Bases: object

BaseConfigSubstitution-like class for use with _create_makefile.


Write out build files necessary to build with recursive make.

class mozbuild.backend.recursivemake.RecursiveMakeTraversal

Bases: object

Helper class to keep track of how the “traditional” recursive make backend recurses subdirectories. This is useful until all adhoc rules are removed from Makefiles.

Each directory may have one or more types of subdirectories:
  • (normal) dirs
  • tests
class SubDirectories

Bases: mozbuild.backend.recursivemake.SubDirectories


alias of SubDirectories

SubDirectoryCategories = [u'dirs', u'tests']
add(dir, dirs=[], tests=[])

Adds a directory to traversal, registering its subdirectories, sorted by categories. If the directory was already added to traversal, adds the new subdirectories to the already known lists.

call_filter(current, filter)

Helper function to call a filter from compute_dependencies and traverse.


Compute make dependencies corresponding to the registered directory traversal.

filter is a function with the following signature:
def filter(current, subdirs)

where current is the directory being traversed, and subdirs the SubDirectories instance corresponding to it. The filter function returns a tuple (filtered_current, filtered_parallel, filtered_dirs) where filtered_current is either current or None if the current directory is to be skipped, and filtered_parallel and filtered_dirs are lists of parallel directories and sequential directories, which can be rearranged from whatever is given in the SubDirectories members.

The default filter corresponds to a default recursive traversal.

static default_filter(current, subdirs)

Default filter for use with compute_dependencies and traverse.


Returns all direct subdirectories under the given directory.

traverse(start, filter=None)

Iterate over the filtered subdirectories, following the traditional make traversal order.


mozbuild.backend.test_manifest module

class mozbuild.backend.test_manifest.TestManifestBackend(environment)

Bases: mozbuild.backend.base.PartialBackend

Partial backend that generates test metadata files.

add(t, flavor, topsrcdir)
add_installs(obj, topsrcdir)

mozbuild.backend.tup module

class mozbuild.backend.tup.BackendTupfile(objdir, environment, topsrcdir, topobjdir, dry_run, default_group)

Bases: object

Represents a generated Tupfile.

rule(cmd, inputs=None, outputs=None, display=None, extra_inputs=None, output_group=None, check_unchanged=False)
class mozbuild.backend.tup.TupBackend(environment)

Bases: mozbuild.backend.common.CommonBackend

Backend that generates Tupfiles for the tup build system.

build(config, output, jobs, verbose, what=None)

Write out build files necessary to build with tup.

mozbuild.backend.visualstudio module

class mozbuild.backend.visualstudio.VisualStudioBackend(environment)

Bases: mozbuild.backend.common.CommonBackend

Generate Visual Studio project files.

This backend is used to produce Visual Studio projects and a solution to foster developing Firefox with Visual Studio.

This backend is currently considered experimental. There are many things not optimal about how it works.

static write_vs_project(fh, version, project_id, name, includes=[], forced_includes=[], defines=[], build_command=None, clean_command=None, debugger=None, headers=[], sources=[])

Module contents