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
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
This patch introduces a new marionette media test along
with a Youtube test.
To run the Youtube streaming test locally:
./mach marionette-test dom/media/test/marionette/test_youtube.py -vv --gecko-log -
Differential Revision: https://phabricator.services.mozilla.com/D23644
--HG--
extra : moz-landing-system : lando
Keep a checksum to avoid re-extracting artifacts over and over.
In the future we can also check the checksum to avoid downloading the artifact
altogether, maybe.
Differential Revision: https://phabricator.services.mozilla.com/D25542
--HG--
extra : moz-landing-system : lando
This patch introduces a new marionette media test along
with a Youtube test.
To run the Youtube streaming test locally:
./mach marionette-test dom/media/test/marionette/test_youtube.py -vv --gecko-log -
Differential Revision: https://phabricator.services.mozilla.com/D23644
--HG--
extra : moz-landing-system : lando
We produce two types of build symbol archives in automation:
- "crashreporter-symbols.zip" contains Breakpad-format .sym files
- "crashreporter-symbols-full.zip" contains Breakpad-format .sym files
and compressed ELF debug symbol .dbg.gz files
Right now, `--enable-artifact-build-symbols` from Bug 1305502
downloads only "crashreporter-symbols.zip".
The Android Studio version of lldb, currently 7.0.0, doesn't support
Breakpad-format .sym files. It does support (uncompressed) ELF debug
symbols. (Note that gdb isn't supported on Android and hasn't been for
some time.)
This makes ` --enable-artifact-build-symbols` download the full
symbols for Android builds that aren't in automation, to be useful for
debugging Android builds with lldb locally.
Differential Revision: https://phabricator.services.mozilla.com/D19091
--HG--
extra : moz-landing-system : lando
It's not helpful to have a DEBUG log level, 'cuz the -v flag to
`./mach artifact install` doesn't turn on DEBUG logging.
Differential Revision: https://phabricator.services.mozilla.com/D19090
--HG--
extra : moz-landing-system : lando
When an added file is not under an app or addon directory, its base
directory is ''. The code added in bug 1539355 would skip doing its
thing in that case, which it shouldn't.
Also revert the workaround from bug 1525762.
We have some convoluted packaging logic to automatically package any directory
with a manifest.json file as an XPI. Unfortunately, that logic also applies to
extensions that are supposed to be part of omni.ja.
It would be nice to have a cleaner way to filter out any resources which we've
already flagged to be part of omni.ja, but this patch takes the simpler
approach of just including anything that's in a modules/ directory, which is
whitelisted for omni.ja elsewhere.
--HG--
extra : source : d30967b60a03f8f4286c26f14342d50e03a59f9d
extra : amend_source : 2ddab7bd7ce2fb666d5335bf9941328d9dd7d66f
We shouldn't pass those flags when building C. It doesn't matter /too/
much currently, but will in a subsequent change, which will introduce
a C++-only flag in stlport_cppflags.
Differential Revision: https://phabricator.services.mozilla.com/D25018
--HG--
extra : moz-landing-system : lando
Practically speaking, it makes no difference, as only the calls to
add_base from tests weren't already ordered.
This allows a simpler approach for next change.
Differential Revision: https://phabricator.services.mozilla.com/D25036
--HG--
extra : moz-landing-system : lando
This demonstrates how addons positioned under a resource directory (a
directory that would normally go in omni.ja) is currently treated.
Differential Revision: https://phabricator.services.mozilla.com/D25035
--HG--
extra : moz-landing-system : lando
Bug 1533425 makes Gecko try to load from $ARCH/greprefs.js, etc on
Android. This patch teaches the packager to put preferences into
those architecture-specific locations for that code to find.
Differential Revision: https://phabricator.services.mozilla.com/D24984
--HG--
extra : moz-landing-system : lando
Mike Shal
Chris Manchester
Bastien Abadie
Andi-Bogdan Postelnicu
Petr Sumbera
Mike Hommey
Andreea Pavel
Dorel Luca
Valentin Gosu
Coroiu Cristina
Razvan Maries
Andrew Halberstadt
Csoregi Natalia
Bogdan Tara
Emilio Cobos Álvarez
Ciure Andrei
Dave Townsend
Tarek Ziadé
Narcis Beleuzu
Nick Alexander
Kris Maglione
Justin Wood
Noemi Erli