Some media libraries use gas syntax in their assembly files. Rather than
converting these arm assembly syntax files for aarch64, we can use clang-cl
to build them directly.
Differential Revision: https://phabricator.services.mozilla.com/D27785
--HG--
extra : moz-landing-system : lando
With this change tooltool.py also supports taskcluster credentials to be passed
(in json format) to --authentication-file option. RelengAPI tokens are still
working with this patch, just additional authentication is added.
Differential Revision: https://phabricator.services.mozilla.com/D27881
--HG--
extra : moz-landing-system : lando
The noatime option doesn't appear to have a significant impact on no-op
build times, even though the build system does a significant number of
file reads. Since macs have atime enabled by default, we should just
disable this check rather than give developers unhelpful error messages.
Differential Revision: https://phabricator.services.mozilla.com/D28906
--HG--
extra : moz-landing-system : lando
For some reason, using `tar -Jxf` with Windows paths fails, and that makes
`mach artifact toolchain` unable to pull .tar.xz archives on Windows.
However, executing `xz -d -c` works, and we can feed its output to
python's tarfile.
Differential Revision: https://phabricator.services.mozilla.com/D28779
--HG--
extra : moz-landing-system : lando
With this change tooltool.py also supports taskcluster credentials to be passed
(in json format) to --authentication-file option. RelengAPI tokens are still
working with this patch, just additional authentication is added.
Differential Revision: https://phabricator.services.mozilla.com/D27881
--HG--
extra : moz-landing-system : lando
Add basic support for 'mach gtest' on Android.
Handling of Android-only and desktop-only options is awkward; I hope to
re-visit this after bug 1519369.
Differential Revision: https://phabricator.services.mozilla.com/D28129
--HG--
extra : moz-landing-system : lando
`caskroom/versions` was replaced with `homebrew/cask-versions` in 2018.
Tap `caskroom/versions` instead of the old one.
If you have two taps, remove the old one using:
brew untap caskroom/versions
Differential Revision: https://phabricator.services.mozilla.com/D27839
--HG--
extra : moz-landing-system : lando
If the user runs mach clang-format from the builddir, it was finding and using
unified files.
Differential Revision: https://phabricator.services.mozilla.com/D27750
--HG--
extra : moz-landing-system : lando
The TestManifestBackend always has a dependency on config.status, even
if configure hasn't been run yet. If configure is run later, this is
intended to cause the TestManifestBackend to be regenerated so that it
can use the configured values instead of a potentially incomplete setup.
Mozbuild's backend_out_of_date() logic treats a missing file as always
being out of date, which means if configure hasn't run, the
TestManifestBackend will always be regenerated.
Instead we can create a stub config.status file that will fix the
out-of-date check, and can be treated as a
BuildEnvironmentNotFoundException as if the file didn't exist at all.
Differential Revision: https://phabricator.services.mozilla.com/D27195
--HG--
extra : moz-landing-system : lando
Bug 1537574 moved some code that uses errno from building.py to base.py,
but the latter didn't already import errno.
Differential Revision: https://phabricator.services.mozilla.com/D27125
--HG--
extra : moz-landing-system : lando
If mozbuild parsing fails due to a missing file (eg: a file not existing
in UNIFIED_SOURCES), then no Makefiles are written out, but
config.status exists. This would cause mozbuild to think that configure
doesn't need to run, and rely on make to perform the backend-out-of-date
check in rebuild-backend.mk. Unfortunately since no Makefiles were
written, the make command fails immediately and no attempt is made to
re-create the backend. Note that this is only a problem if the first
mozbuild parsing from a clobber build fails, otherwise there is
typically a top-level Makefile from a previous build to call into (at
which point make can determine it is out-of-date, and re-invoke itself).
The fix is to have the RecursiveMake backend re-use the same logic that
was introduced into mozbuild for alternate backends, and remove
rebuild-backend.mk. This way, mozbuild can always determine if the
backend needs to be regenerated, even if the initial parsing failed.
Test code was also relying on rebuild-backend.mk to generate the
TestBackend, but moving backend_out_of_date() into MozbuildObject allows
this code to be shared.
Differential Revision: https://phabricator.services.mozilla.com/D26262
--HG--
rename : build/gen_test_backend.py => python/mozbuild/mozbuild/gen_test_backend.py
extra : moz-landing-system : lando
If there are a large number of untracked files in the working directory, hg
will attempt to print them all out with the default pager. This does not
interact very will with commands that are built atop this functionality. We
set HGPLAIN=1 so that the underlying hg will not attempt to use a pager.
Differential Revision: https://phabricator.services.mozilla.com/D26607
--HG--
extra : moz-landing-system : lando
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
If mozbuild parsing fails due to a missing file (eg: a file not existing
in UNIFIED_SOURCES), then no Makefiles are written out, but
config.status exists. This would cause mozbuild to think that configure
doesn't need to run, and rely on make to perform the backend-out-of-date
check in rebuild-backend.mk. Unfortunately since no Makefiles were
written, the make command fails immediately and no attempt is made to
re-create the backend. Note that this is only a problem if the first
mozbuild parsing from a clobber build fails, otherwise there is
typically a top-level Makefile from a previous build to call into (at
which point make can determine it is out-of-date, and re-invoke itself).
The fix is to have the RecursiveMake backend re-use the same logic that
was introduced into mozbuild for alternate backends, and remove
rebuild-backend.mk. This way, mozbuild can always determine if the
backend needs to be regenerated, even if the initial parsing failed.
Test code was also relying on rebuild-backend.mk to generate the
TestBackend, but moving backend_out_of_date() into MozbuildObject allows
this code to be shared.
Differential Revision: https://phabricator.services.mozilla.com/D26262
--HG--
rename : build/gen_test_backend.py => python/mozbuild/mozbuild/gen_test_backend.py
extra : moz-landing-system : lando
Geoff Brown
Dan Minor
Bastien Abadie
Chris Manchester
Mike Hommey
Rok Garbas
Panagiotis Astithas
Mike Shal
Kartikaya Gupta
Andi-Bogdan Postelnicu
Christian Frey
Cosmin Sabou
Ciure Andrei
Rob Wu
Csoregi Natalia
Sylvestre Ledru
Mike Shal
Bobby Holley
Nicholas Cowles
Aaron Klotz
Petr Sumbera
Andreea Pavel
Dorel Luca
Valentin Gosu
Coroiu Cristina
Avery Berninger
Razvan Maries