Overall, this makes the whole setup less fragile, and make it work with
LTO in more situations.
--HG--
extra : rebase_source : de968c61dc4ef337fdc28745c202334ac41763cd
Our bundled Hunspell now significantly differs from upstream Hunspell. Most
importantly, it supports loading dictionaries from jar: URIs, which is now a
requirement for loading bundled and extension dictionaries. This means that
system Hunspell libraries are no longer compatible with our spell checker
code. We should remove the option to use them so that users don't fall into
the trap of trying to use them.
MozReview-Commit-ID: 2ihJe6YOnGf
--HG--
extra : rebase_source : ceb091b9475a2b101156405a02a60015fc36da17
We don't add build-time dependency on Wayland libraries; that allows Wayland enabled Firefox
builds to run on systems without Wayland support.
We also can't dlsym() Wayland symbols directly from libwayland-client.so library as we miss
global data entries referenced by code at wayland-client.h then.
As a partial solution (for glibc systems only) we create dummy libwayland-client.so library
implementation and place it *after* Gtk+ 3.0 libraries at linking time.
It fixes build-time dependencies (we link against our libwayland-client.so library).
Run-time dependency is resolved by ld.so - when Gtk+ 3.0 libraries are linked with
system libwayland-client.so library, wayland symbols are pulled from there instead
from our dummy libwayland-client.so library.
When Gtk+ 3.0 is not linked with system libwayland-client.so it means we're running
on system without Wayland support. Our dummy libwayland-client.so implementation
is used (symbols are pulled run-time from there) and Firefox Wayland support is
disabled then.
MozReview-Commit-ID: IyaePwp4MxV
--HG--
extra : rebase_source : 852955d001657176e0bf69c099580be862d0b448
This patch removes the ability to select which protocols you want
included in necko, a wholly untested configuration that is broken in
practice. We have no need of this kind of configurability in necko.
In addition, this removes the final vestiges of rtsp support, which was
originally removed in bug 1295885 but still had some stuff hanging
around behind some ifdefs (that were never true).
MozReview-Commit-ID: KOEaDmit2IL
--HG--
extra : rebase_source : f6c2fdb972aaba46e922cda801252dc953550b94
This is a simple workaround, but it could be replaced by something cleaner
(see bugzilla).
MozReview-Commit-ID: KNgbqVkSXki
--HG--
extra : rebase_source : 2dd84c0e4e4e3b2bf8924bac1f648b73eb41fe45
We now have code that unconditionally requires the rust
compiler and are committed to adding more. Remove this
last vestige of conditional support.
MozReview-Commit-ID: EK6FBnAbR
--HG--
extra : rebase_source : 6efda10a74f9ca0482304c2b1ffe6941e42138f8
Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
WINVER=0x0601 implies PSAPI_VERSION=2. We should not mix PSAPI_VERSION.
MozReview-Commit-ID: Ckxel4JNW2x
--HG--
extra : rebase_source : 3dc221ca67642ea810cb353869f76b82c40c7bf3
CLOSED TREE
MozReview-Commit-ID: 11qJbfim7Lm
--HG--
extra : source : d332de44654828b81e2ad13ec2d7fe54eb8d2de9
extra : intermediate-source : 614a80e577f3757a61a00235f76d961d1c86a587
WINVER=0x0601 implies PSAPI_VERSION=2. We should not mix PSAPI_VERSION.
MozReview-Commit-ID: Ckxel4JNW2x
--HG--
extra : rebase_source : 932c67a3cae063fe4b0c5fec9048e67ce6286ad3
To validate the PSSH init data passed to EME, I'd like to reuse the same
PSSH parser that the ClearKey CDM shared library uses. So move the code
out of gmp-clearkey and into its own library, so we can link it statically
into code that needs to use it.
MozReview-Commit-ID: 7xSUSmCueJz
--HG--
rename : media/gmp-clearkey/0.1/ClearKeyCencParser.cpp => media/psshparser/PsshParser.cpp
rename : media/gmp-clearkey/0.1/ClearKeyCencParser.h => media/psshparser/PsshParser.h
extra : source : 78dcbc5d3c26547c63269eb14034a67863cf28de
When building gtest libxul with LTO, the fact that
StaticXULComponentStart is not passed first to the linker makes the
linker pull the NSModule symbols out of all the other objects first,
presumably because linking the gtest objects (which appear first) pulls
code from the other non StaticXULComponent* objects first.
So, to make things link properly with LTO, we trick the build system
to always put StaticXULComponentStart first.
--HG--
extra : rebase_source : 7ddda118903f5845f6b6d12db2bf39cd22d67ab5
Subtly, as toolkit/moz.configure happens before toolchain tests, we
can't set MOZ_SERVO_LIBS from there. And toolkit/moz.configure is
not always included either, making things awkward to do in python
configure.
OTOH, there's only one place where MOZ_SERVO_LIBS is used, and the
corresponding setup can actually be done there (in moz.build) instead.
I think we shouldn't shy away from moving things this way.
This patch is really two separate changes.
The first change is that rust crates are large, standalone entities that
may contain multitudes of source files. It therefore doesn't make sense
to keep them in SOURCES, as we have been doing. Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.
The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers. By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.
The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.
We also clean up a number of leftover things from the Old Way of doing
things. A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
This patch is really two separate changes.
The first change is that rust crates are large, standalone entities that
may contain multitudes of source files. It therefore doesn't make sense
to keep them in SOURCES, as we have been doing. Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.
The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers. By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.
The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.
We also clean up a number of leftover things from the Old Way of doing
things. A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
Current stable versions of Rust use two Rust-specific personality
routines to perform exception handling, which empirically does not play
well with the Mac linker's optimizations for using compact unwind
formats. Nightly Rust has solved this issue, but for now, we'll have to
use -no_compact_unwind to disable the linker optimization. The size
impact is negligible (0.02%) and will be going away once nightly Rust
becomes stable.
Current stable versions of Rust use two Rust-specific personality
routines to perform exception handling, which empirically does not play
well with the Mac linker's optimizations for using compact unwind
formats. Nightly Rust has solved this issue, but for now, we'll have to
use -no_compact_unwind to disable the linker optimization. The size
impact is negligible (0.02%) and will be going away once nightly Rust
becomes stable.
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
