The buildconfig module predates MozbuildObject.from_environment, and
it's about time to start factoring things out such that we only have
one way to get config.status data. This is step 1: making the
buildconfig module use MozbuildObject.from_environment.
Eventually, we'll want to remove the buildconfig module uses everywhere.
The topobjdir-finding logic in mozbuild relies on MOZ_CURRENT_PROJECT
being set, and it's currently only set when going through client.mk.
On automation, during universal builds, make check is invoked directly
in one of the objdirs, so MOZ_CURRENT_PROJECT is not set. We've had
other similar problems in the past. Ensuring MOZ_CURRENT_PROJECT is set
in the objdir itself should reduce the risk of other such issues in the
future.
Historically, a mozinfo for js standalone build has not been necessary,
but with the move towards a) having things work with mach and b)
buildconfig using the MozbuildObject.from_environment in next patch,
mozinfo becomes necessary (it's required for
MozbuildObject.from_environment to find the directory is an objdir).
Interestingly, hazard builds do both a js standalone build and a desktop
Firefox build at the same time, both of which are done with MOZCONFIG
set in the environment... with the Firefox mozconfig. The result of now
writing a mozinfo for js standalone builds is that in that case, they
end up with a reference to the mozconfig, which the build system then
reads, and finds a MOZ_OBJDIR, which then doesn't match the js
standalone build objdir. So for those builds, reset MOZCONFIG.
This patch bundles a color font named "EmojiOne Mozilla", and turn on
the necessary code for including the bundled font, on Linux and Windows.
With that, users of Linux and Windows <=8.0 is able to see color Emoji
on Firefox without support from System.
The font bundled is the v0.2.1 version, generated from the project repo
in
https://github.com/mozilla/emojione-colr
with artwork from the original EmojiOne font and Twemoji,
under CC BY 4.0 license.
Test files, about:license page, and the packager instruction are
modified accordingly.
MozReview-Commit-ID: 2mmxnA0vS3u
--HG--
extra : rebase_source : 34008d9063fa0ecf95d4f76d645f0d40635290ba
The idl-test-harness can't detect the multiple types in webidl [1], so it doesn't know about the type like "double or AutoKeyword".
The same problem also happen in VTTCue's line property, and we have already expected its fail.
Therefore, we should expect this fail before we fix the problem of idl-test-harness.
[1] http://searchfox.org/mozilla-central/source/dom/imptests/idlharness.js#375
MozReview-Commit-ID: 5XvOwdmqKDP
--HG--
extra : rebase_source : fd72ef43d1f24792a1b3e228da7a7dca9483b1da
Jobs reporting to treeherder should rely on the task route for project,
revision, and pushlog ID rather than things stuffed into task.extra.treeherder.
This also removes the need for a revision_hash that was calculated by mozilla-taskcluster.
MozReview-Commit-ID: EcQM9QRZzgG
--HG--
extra : rebase_source : f04f6724feef2dd51b4b98c67c9a261b093f452b
extra : amend_source : 0590605834d93359206f49edd94396c43b57f6dd
Adding jobKind to task definitions allow tasks to be categorized appropriately on
treeherder once jobs are consumed via pulse messages. The available options are:
test, build, and other.
This should cover most of the tasks within the graph and if there are any issues,
it will not cause the job to not show up, but might affect job failure color.
Any tasks not covered by this change will default to "other" within treeherder.
MozReview-Commit-ID: 6fq25JvpDXz
--HG--
extra : rebase_source : 8670f45d51941d978a44596cc6e9ceb4e85efd3c
Until now, we had some STL headers listed in the system-headers list
such that they would get a system wrapper, but not all of them.
On the other hand, the STL wrappers do the same job as the system
wrappers (applying default visibility), on top of their own, so the
presence of the STL headers in system-headers wasn't making much of a
difference.
Except we have places in the tree where we can't build with STL wrappers
for a number of reasons. And in that case, we *do* need system wrappers
for the STL headers, but we didn't have system wrappers for all of them.
So instead of relying on the STL headers being listed both in
system-headers and stl-headers, concatenate both lists to create the
system wrappers.
Andrew Comminos
Mike Hommey
Bob Silverberg
moby
Onno Ekker
Timothy Guan-tin Chien
Gijs Kruitbosch
Drew Willcoxon
Mike de Boer
DimiL
Alastor Wu
Christoph Kerschbaumer
Thomas Nguyen
Franziskus Kiefer
Gregory Arndt
Andrea Marchesini
Mason Chang
Jonathan Kew
Neil Deakin
Sotaro Ikeda
Jan Varga
Kyle Huey
Sebastian Hengst