This does many things:
1) stops producing (and consuming) `FennecJNI*` JNI wrappers
2) removes the :app and :thirdparty Gradle projects
3) removes relevant pieces of the Gradle target configuration
4) updates lints
5) purges old configurations
After this commit, the `mobile/android` project/application builds
only GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D46536
--HG--
extra : moz-landing-system : lando
Environment should be bytes on Python 2 (to avoid Windows errors) and text on
Python 3. The 'ensure_subprocess' env utility function handles this.
Differential Revision: https://phabricator.services.mozilla.com/D48115
--HG--
extra : moz-landing-system : lando
This logic is very 'mozill-central' specific and should live outside of mach
core if possible. Luckily we already have a concept of a 'pre_dispatch_handler'
that is meant for exactly this type of use case.
Differential Revision: https://phabricator.services.mozilla.com/D47668
--HG--
extra : moz-landing-system : lando
Bug 1580996 cleaned up handling of `{application,platform}.ini` but
inadvertently populated `.ini` files from test archives into the
object directory. That causes issues, especially on try. Test INI
files should come from the local artifact build and not from the
upstream test archives.
Rather than re-instate the test at the time when processed test
archives are _unpacked_, the test is done as test archives are
packed/processed.
Differential Revision: https://phabricator.services.mozilla.com/D46862
--HG--
extra : moz-landing-system : lando
The `freestanding` library is built with specific compiler flags to signify
that it is indeed freestanding code. That is, it does not depend on a
standard library.
One of the requirements of freestanding code is that the toolchain still
expects implementations of `memcpy`, `memmove`, `memcmp`, and `memset`.
I did briefly implement my own naive versions of these functions, but that
solution is less than ideal since the implementations must be `extern` and are
thus picked up by the entire `firefox.exe` binary. This denies the rest of
`firefox.exe` the benefit of optimized implementations. On Windows, the
sandbox is linked into `firefox.exe`, so we cannot just shrug and
assume that naive implementations will not have any effect on anything.
There are, however, optimized implementations of these functions that are
exported by `ntdll.dll`. They are not included in the `ntdll.lib` that is
included in the Windows SDK. Using `llvm-dlltool`, we can build an import
library containing the missing entries and then add that library to `OS_LIBS`.
Depends on D43156
Differential Revision: https://phabricator.services.mozilla.com/D43157
--HG--
extra : moz-landing-system : lando
The `freestanding` library is built with specific compiler flags to signify
that it is indeed freestanding code. That is, it does not depend on a
standard library.
One of the requirements of freestanding code is that the toolchain still
expects implementations of `memcpy`, `memmove`, `memcmp`, and `memset`.
I did briefly implement my own naive versions of these functions, but that
solution is less than ideal since the implementations must be `extern` and are
thus picked up by the entire `firefox.exe` binary. This denies the rest of
`firefox.exe` the benefit of optimized implementations. On Windows, the
sandbox is linked into `firefox.exe`, so we cannot just shrug and
assume that naive implementations will not have any effect on anything.
There are, however, optimized implementations of these functions that are
exported by `ntdll.dll`. They are not included in the `ntdll.lib` that is
included in the Windows SDK. Using `llvm-dlltool`, we can build an import
library containing the missing entries and then add that library to `OS_LIBS`.
Differential Revision: https://phabricator.services.mozilla.com/D43157
--HG--
extra : moz-landing-system : lando
The `freestanding` library is built with specific compiler flags to signify
that it is indeed freestanding code. That is, it does not depend on a
standard library.
One of the requirements of freestanding code is that the toolchain still
expects implementations of `memcpy`, `memmove`, `memcmp`, and `memset`.
I did briefly implement my own naive versions of these functions, but that
solution is less than ideal since the implementations must be `extern` and are
thus picked up by the entire `firefox.exe` binary. This denies the rest of
`firefox.exe` the benefit of optimized implementations. On Windows, the
sandbox is linked into `firefox.exe`, so we cannot just shrug and
assume that naive implementations will not have any effect on anything.
There are, however, optimized implementations of these functions that are
exported by `ntdll.dll`. They are not included in the `ntdll.lib` that is
included in the Windows SDK. Using `llvm-dlltool`, we can build an import
library containing the missing entries and then add that library to `OS_LIBS`.
Differential Revision: https://phabricator.services.mozilla.com/D43157
--HG--
extra : moz-landing-system : lando
The `freestanding` library is built with specific compiler flags to signify
that it is indeed freestanding code. That is, it does not depend on a
standard library.
One of the requirements of freestanding code is that the toolchain still
expects implementations of `memcpy`, `memmove`, `memcmp`, and `memset`.
I did briefly implement my own naive versions of these functions, but that
solution is less than ideal since the implementations must be `extern` and are
thus picked up by the entire `firefox.exe` binary. This denies the rest of
`firefox.exe` the benefit of optimized implementations. On Windows, the
sandbox is linked into `firefox.exe`, so we cannot just shrug and
assume that naive implementations will not have any effect on anything.
There are, however, optimized implementations of these functions that are
exported by `ntdll.dll`. They are not included in the `ntdll.lib` that is
included in the Windows SDK. Using `llvm-dlltool`, we can build an import
library containing the missing entries and then add that library to `OS_LIBS`.
Differential Revision: https://phabricator.services.mozilla.com/D43157
--HG--
extra : moz-landing-system : lando
It was added in bug 1575760 and turns out to be causing a lot more
problems than anticipated.
However, the previous status quo is also not ideal, so we do
auto-generate .cargo/config.in instead, with a little trick that allows
to just copy it to .cargo/config instead of how individual scripts would
previously manually preprocess it.
Differential Revision: https://phabricator.services.mozilla.com/D46138
--HG--
extra : moz-landing-system : lando
