For files that come from the objdir in install manifests (eg: '!buildid.h'),
the FasterMake backend runs 'make -C dirname filename' to build the file
with the RecursiveMake backend before the install manifest is processed.
This works fine for GENERATED_FILES that produce a single target, but if
the GENERATED_FILES invocation produces multiple targets, the FasterMake
backend will run the command multiple times. Eg:
GENERATED_FILES += [('output1', 'output2')]
...
make -C dirname output1
make -C dirname output2
These invocations may be run in parallel, and would produce both output1
and output2 twice.
Instead we can track the GeneratedFile objects as they are emitted, and
only add the first output as a dependency on the install manifest. The
RecursiveMake backend is then only invoked once for the whole group of
GENERATED_FILES.
MozReview-Commit-ID: 6mvkHow2V2i
--HG--
extra : rebase_source : c6cd50d972fe8764831544685a63921e0548e765
This also enables the py2 linter which will help maintain compatibility
with both 2 and 3.
Differential Revision: https://phabricator.services.mozilla.com/D1884
--HG--
extra : moz-landing-system : lando
XPIDL files are logically grouped together into a module, but the
current model for the moz.build frontend is that we emit individual
XPIDLFile objects, and leave it to the backend to reconstruct
module-ness from those. This setup causes a small amout of useless work
to be done (e.g. see XPIDLFile handling in
RecursiveMakeBackend.consume_object; such handling should only be done
once), and it would be cleaner to have the objects emitted reflect the
build system concepts as closely as possible. To that end, let's emit
XPIDLModule objects instead, which fortunately requires relatively few
changes.
The IDLManager in the moz.build backend is a bit weird. It maintains a
bunch of per-IDL file information, some of which isn't used, and
attempts to map module names to information about what entities the
module needs to be built. The former is done with Python dicts, and the
latter with Python tuples, both resulting in some contortions by the
clients of IDLManager to specify exactly what they need.
Let's clean this up, by making IDLManager to more clearly do two jobs:
1. Keep track of whether IDL files are globally unique; and
2. Map module names to the information needed to build them.
In the case of #2, we store everything as a straight Python object, so
we can use actual property accesses everywhere. We also provide a
stems() function on IDLManager to make some client code more
straightforward.
Doing this makes IDLManager much more XPIDL module-centric, and paves
the way for the same change to be made in the frontend as well.
XPIDL_SOURCES would benefit from being more explicit about what sort of
values it contains; let's define it as a list of SourcePath objects, and
propagate those objects into XPIDLFile frontend objects as well.
Co-authored by Nick Alexander <nalexander@mozilla.com>
This patch adds support to the fastermake backend for taking localized files
from a locale directory as specified by the combination of --with-l10n-base
and --enable-ui-locale. This allows artifact builds to be built localized
with a different locale.
MozReview-Commit-ID: 1bD9Gy0ewJ2
--HG--
extra : rebase_source : 7e7d52142e48c0e57ead11df4d3d721a3b10b3e0
XPIDL files are logically grouped together into a module, but the
current model for the moz.build frontend is that we emit individual
XPIDLFile objects, and leave it to the backend to reconstruct
module-ness from those. This setup causes a small amout of useless work
to be done (e.g. see XPIDLFile handling in
RecursiveMakeBackend.consume_object; such handling should only be done
once), and it would be cleaner to have the objects emitted reflect the
build system concepts as closely as possible. To that end, let's emit
XPIDLModule objects instead, which fortunately requires relatively few
changes.
The IDLManager in the moz.build backend is a bit weird. It maintains a
bunch of per-IDL file information, some of which isn't used, and
attempts to map module names to information about what entities the
module needs to be built. The former is done with Python dicts, and the
latter with Python tuples, both resulting in some contortions by the
clients of IDLManager to specify exactly what they need.
Let's clean this up, by making IDLManager to more clearly do two jobs:
1. Keep track of whether IDL files are globally unique; and
2. Map module names to the information needed to build them.
In the case of #2, we store everything as a straight Python object, so
we can use actual property accesses everywhere. We also provide a
stems() function on IDLManager to make some client code more
straightforward.
Doing this makes IDLManager much more XPIDL module-centric, and paves
the way for the same change to be made in the frontend as well.
XPIDL_SOURCES would benefit from being more explicit about what sort of
values it contains; let's define it as a list of SourcePath objects, and
propagate those objects into XPIDLFile frontend objects as well.
Co-authored by Nick Alexander <nalexander@mozilla.com>
This patch adds support to the fastermake backend for taking localized files
from a locale directory as specified by the combination of --with-l10n-base
and --enable-ui-locale. This allows artifact builds to be built localized
with a different locale.
MozReview-Commit-ID: 1bD9Gy0ewJ2
--HG--
extra : rebase_source : 9f457c8565ff0297589533ab91b44c16edc86be3
We shouldn't call _get_backend_file during TupBackend:_init() since
self.dry_run is not set yet. Instead we can just call it when we need to
add rust rules.
MozReview-Commit-ID: 5elqXGFMSuG
--HG--
extra : rebase_source : 880a754f631f691aaf85bfda610e29b7bfcb89b4
a35b188d0e44 inadvertently regressed behavior in the case where
the Git status.showUntrackedFiles config option was set and
we want to purge untracked files.
Differential Revision: https://phabricator.services.mozilla.com/D2141
--HG--
extra : moz-landing-system : lando
The doc string for the "working_directory_clean" function states:
> By default, untracked and ignored files are not considered.
But the git implementation for this function used to run:
git status --porcelain
Which *does* consider untracked files by default. Instead, we need to run:
git status --porcelain --untracked-files=no
Differential Revision: https://phabricator.services.mozilla.com/D2134
--HG--
extra : moz-landing-system : lando
This patch uses the PIPENV_PYTHON environment variable to append a suffix to the created virtual environment path according to the version specified. It also uses the PIPENV_DEFAULT_PYTHON_VERSION environment variable to avoid recreating the virtual environment every time. With these changes we are able to switch back and forth between Python versions without the expense of recreating environments, however there is a risk of these environments becoming stale. In this scenario it may be necessary to clobber the virtual environment root within the obj dir.
MozReview-Commit-ID: C4vuwNh04CP
--HG--
extra : rebase_source : 301c8418fe5b873ffadec37af11e98cfda8667b8
Most HG commands use subprocesses, even if a context manager (and therefore an
hglib client) has been created. There are only two commands that make use of
the client, but they *only* work inside a context manager. I don't think
there are any technical reason these two commands *need* to use the context
manager.
This patch merges the HgRepository._run_in_client function with
HgRepository._run(). If a client exists, that will be used, otherwise a
subprocess will be used.
Differential Revision: https://phabricator.services.mozilla.com/D1809
--HG--
extra : moz-landing-system : lando
This patch uses the PIPENV_PYTHON environment variable to append a suffix to the created virtual environment path according to the version specified. It also uses the PIPENV_DEFAULT_PYTHON_VERSION environment variable to avoid recreating the virtual environment every time. With these changes we are able to switch back and forth between Python versions without the expense of recreating environments, however there is a risk of these environments becoming stale. In this scenario it may be necessary to clobber the virtual environment root within the obj dir.
MozReview-Commit-ID: C4vuwNh04CP
--HG--
extra : rebase_source : ba34e415fa21683bc2a39231651587fa30ad0242
For clang-cl, we want to add code to libxul that only exists during the
PGO generation phase, so we can collect data. The most expedient way to
do that is to enable certain files in SOURCES to be marked as to only be
compiled during the PGO generation step.
