Mesa 9.2.1 looks to be leaking debug messages and I can't figure out how
to make it stop. The upstream code has been entirely rewritten so it's
probably not worth investigating further.
The behavior is not entirely idempotent (most notably for
buildconfig.html), but this can be improved later if necessary.
It is idempotent where it matters.
This allows to get rid of config/makefiles/rcs.mk and its uses.
There is an ImportError on Android, as well as a log related
regression from the structured log patch once that is fixed.
MozReview-Commit-ID: KxSEotr38qO
--HG--
extra : rebase_source : 15d8421aab813d9e0dbf6d00611f921aaa779a49
This adds a post_dispatch_handler hook that will be called after each
mach invocation and uses it to submit data to telemetry.
--HG--
extra : rebase_source : 1dedea568b7ccec17fa58eb1841425b165d8a644
On a CLOSED TREE because this is Android only.
When we switched to fine-grained Google Play Services bundling (Bug
1115004), we stopped shipping com.google.android.gms.analytics. That
silently breaks Adjust, which queries the Google Ad ID using
reflection: now the package isn't present! This patch restores the
Play Services libraries that Adjust relies on. (Sadly, this bloats
our APK tremendously.)
There is some hijinkery, however: the Play Services libraries
reference a library (org.apache.http) that is deprecated in Android
23! However, the library is still present on Android 23 devices,
which buys Google time to replace the offending code. This compiles
just fine, breaks the Proguard global optimization pass. To give
Proguard the information, we add the library as a Proguard "library
JAR". This is equivalent to the Google-provided Gradle `useLibrary`
directive.
--HG--
extra : commitid : I4rTyC8lxLd
extra : rebase_source : 96f30d735e898cb9853d53f236ac8e2337186814
extra : amend_source : 3e4d68789b3ef980e4e1d7f743e332bdbb6be176
Structured logs bring many benefits. We can stop parsing the logs for magic strings, we
can modify the format without breaking things, and we can stream results into systems like
ActiveData. The structured logs originate primarily in reftest.js. StructuredLog.jsm is
used to generate the JSON-based log stream. Finally OutputHandler in the python harness
reads structured output from stdout, and formats it into human readable form.
MozReview-Commit-ID: G3ZLkMRl6p7
--HG--
extra : commitid : J3ui9XYWR3Q
extra : rebase_source : 77ed0ba842cc8e557141fb3494212b06868c728a
extra : amend_source : 735d48225a2e627e0fe45fc11b50b6c49a885a4b
extra : source : d1779fe421c3c7cd8e3d191816776390dc104f37
This adds a telemetry_handler function to the mach context that can be
used to store telemetry data in the state directory for later reporting.
--HG--
extra : rebase_source : da1635106d20282b5e722f9bae57de93fdc4211e
msys-perl-wrapper was used to transform windows paths after the -I flag,
which was a preprocessor flag, which a) doesn't exist anymore and b) the
preprocessor has not even be in perl for years.
Currently it will fail with errors such as:
Insufficient debug information (private symbols are needed) or code from
unknown language. The following modules didn't have full symbols:
nsBrowserApp.obj
AppData.obj (xpcomglue_staticruntime.lib)
FileUtils.obj (xpcomglue_staticruntime.lib)
nsCRTGlue.obj (xpcomglue_staticruntime.lib)
nsXPCOMGlue.obj (xpcomglue_staticruntime.lib)
We need to turn this back on when clang-cl grows more debug
info support.
Structured logs bring many benefits. We can stop parsing the logs for magic strings, we
can modify the format without breaking things, and we can stream results into systems like
ActiveData. The structured logs originate primarily in reftest.js. StructuredLog.jsm is
used to generate the JSON-based log stream. Finally OutputHandler in the python harness
reads structured output from stdout, and formats it into human readable form.
--HG--
extra : commitid : J3ui9XYWR3Q
extra : rebase_source : 6bae978126dbd5beddc39332c7cbce0c1354cd87
extra : amend_source : 735d48225a2e627e0fe45fc11b50b6c49a885a4b
We have very few directories where we have SOURCES declared that are not
part of a library or program in some way. In fact, there is only one
where it is legitimate because we only use the object file
(build/unix/elfhack/inject). Others are the result of moz.build control
flow (see e.g. netwerk/standalone), and we end up building more objects
than we need to.
There are other cases where we need objects without actually linking
them anywhere, but there are other sources in the same directory, and a
corresponding Linkable is emitted. And in fact, the only case I knew
about (media/libvpx), doesn't use such objects since bug 1151175.
Some methods may not have names. NamedDecl::getName() already returns
an empty string for those, but it also asserts the consumer is asking
for something that makes sense.
Now that we have cross-compilation tooltool packages for OS X, we can
use the common mozconfig to enable Rust on all OS X builds, regardless
of host OS.
rustc, unlike our typical C++ compilers, can target multiple platforms
with ease through its use of the --target flag. To support
cross-compiling, we just need to pass the appropriate --target option.
rustc uses specific names for its accepted --target option, however, and
they are slightly different from the values we get out of autoconf. So
in addition to checking whether rustc can accept --target for our chosen
platform, we also need to munge autoconf's idea of the target into
something rustc understands.
