mozbuild.backend package¶
Submodules¶
mozbuild.backend.base module¶
- class mozbuild.backend.base.BuildBackend(environment)¶
Bases:
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 client.mk’ should run.
- consume(objs)¶
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.
- consume_finished()¶
Called when consume() has completed handling all objects.
- abstract consume_object(obj)¶
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.
- summary()¶
- mozbuild.backend.base.HybridBackend(*backends)¶
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:
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.clangd module¶
- class mozbuild.backend.clangd.ClangdBackend(environment)¶
Bases:
CompileDBBackend
Configuration that generates the backend for clangd, it is used with clangd extension for vscode
- mozbuild.backend.clangd.find_vscode_cmd()¶
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:
BuildBackend
Holds logic common to all build backends.
- consume_finished()¶
Called when consume() has completed handling all objects.
- consume_object(obj)¶
Consumes an individual TreeMetadata instance.
This is the main method used by child classes to react to build metadata.
- localized_path(relativesrcdir, filename)¶
Return the localized path for a file.
Given
relativesrcdir
, a path relative to the topsrcdir, return a path tofilename
from the current locale as specified byMOZ_UI_LOCALE
, usingL10NBASEDIR
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.
- idl_stems()¶
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.
- link_module(module)¶
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, 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.
substs is a dict filled from AC_SUBST in autoconf.
ConfigEnvironment automatically defines one additional substs variable from all the 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 autoconf.mk. 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 autoconf.mk..
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.
- acdefines¶
A specialized version of the memoize decorator that works for class instance properties.
- static from_config_status(path)¶
- property is_artifact_build¶
- exception mozbuild.backend.configenvironment.ConfigStatusFailure¶
Bases:
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)¶
- iteritems()¶
- 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:
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.
- get_dependencies()¶
- write_vars(config)¶
mozbuild.backend.cpp_eclipse module¶
- class mozbuild.backend.cpp_eclipse.CppEclipseBackend(environment)¶
Bases:
CommonBackend
Backend that generates Cpp Eclipse project files.
- consume_finished()¶
Called when consume() has completed handling all objects.
- consume_object(obj)¶
Consumes an individual TreeMetadata instance.
This is the main method used by child classes to react to build metadata.
- static get_workspace_path(topsrcdir, topobjdir)¶
- summary()¶
mozbuild.backend.fastermake module¶
- class mozbuild.backend.fastermake.FasterMakeBackend(environment)¶
Bases:
MakeBackend
,PartialBackend
- consume_finished()¶
Called when consume() has completed handling all objects.
- consume_object(obj)¶
Consumes an individual TreeMetadata instance.
This is the main method used by child classes to react to build metadata.
mozbuild.backend.mach_commands module¶
- mozbuild.backend.mach_commands.get_clang_tools(command_context, clang_tools_path)¶
- mozbuild.backend.mach_commands.get_eclipse_workspace_path(command_context)¶
- mozbuild.backend.mach_commands.get_visualstudio_workspace_path(command_context)¶
- mozbuild.backend.mach_commands.prompt_bool(prompt, limit=5)¶
Prompts the user with prompt and requires a boolean value.
- mozbuild.backend.mach_commands.run(command_context, ide, no_interactive, args)¶
- mozbuild.backend.mach_commands.setup_clangd_rust_in_vscode(command_context)¶
- mozbuild.backend.mach_commands.setup_vscode(command_context, interactive)¶
mozbuild.backend.make module¶
- class mozbuild.backend.make.MakeBackend(environment)¶
Bases:
CommonBackend
Class encapsulating logic for backends that use Make.
mozbuild.backend.recursivemake module¶
- class mozbuild.backend.recursivemake.BackendMakeFile(srcdir, objdir, environment, topsrcdir, topobjdir, dry_run)¶
Bases:
object
Represents a generated backend.mk 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 backend.mk as well as the Makefile.in (if it exists) are in the GLOBAL_DEPS list. This means that if one of them changes, all targets in that Makefile are invalidated. backend.mk 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 moz.build files (the whole tree is scanned as opposed to individual files), if we were to blindly write backend.mk files, the net effect of updating a single mozbuild file in the tree is all backend.mk 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 backend.mk files unless they actually change. We use FileAvoidWrite to accomplish this.
- add_statement(stmt)¶
- close()¶
- property diff¶
- write(buf)¶
- write_once(buf)¶
- class mozbuild.backend.recursivemake.RecursiveMakeBackend(environment)¶
Bases:
MakeBackend
Backend that integrates with the existing recursive make build system.
This backend facilitates the transition from Makefile.in to moz.build files.
This backend performs Makefile.in -> Makefile conversion. It also writes out .mk files containing content derived from moz.build 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 Makefile.in 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.
- config¶
- input_path¶
- output_path¶
- topobjdir¶
- topsrcdir¶
- consume_finished()¶
Called when consume() has completed handling all objects.
- consume_object(obj)¶
Write out build files necessary to build with recursive make.
- summary()¶
- 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:
SubDirectories
- SubDirectoriesTuple¶
alias of
SubDirectories
- SubDirectoryCategories = ['dirs', '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_dependencies(filter=None)¶
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.
- get_subdirs(dir)¶
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.recursivemake.make_quote(s)¶
mozbuild.backend.static_analysis module¶
- class mozbuild.backend.static_analysis.StaticAnalysisBackend(environment)¶
Bases:
CompileDBBackend
mozbuild.backend.test_manifest module¶
- class mozbuild.backend.test_manifest.TestManifestBackend(environment)¶
Bases:
PartialBackend
Partial backend that generates test metadata files.
- add(t, flavor, topsrcdir)¶
- add_defaults(manifest)¶
- add_installs(obj, topsrcdir)¶
- consume_finished()¶
Called when consume() has completed handling all objects.
- consume_object(obj)¶
Consumes an individual TreeMetadata instance.
This is the main method used by child classes to react to build metadata.
mozbuild.backend.visualstudio module¶
- class mozbuild.backend.visualstudio.VisualStudioBackend(environment)¶
Bases:
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.
- consume_finished()¶
Called when consume() has completed handling all objects.
- consume_object(obj)¶
Consumes an individual TreeMetadata instance.
This is the main method used by child classes to react to build metadata.
- summary()¶
- static write_vs_project(fh, version, project_id, name, includes=[], forced_includes=[], defines=[], build_command=None, clean_command=None, debugger=None, headers=[], sources=[])¶
- mozbuild.backend.visualstudio.get_id(name)¶
- mozbuild.backend.visualstudio.visual_studio_product_to_platform_toolset_version(version)¶
- mozbuild.backend.visualstudio.visual_studio_product_to_solution_version(version)¶
Module contents¶
- mozbuild.backend.get_backend_class(name)¶