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
netapi32's API isn't used at startup and browsing page. So netapi32 should move to delay load DLLs.
MozReview-Commit-ID: 1g25lnuwbfY
--HG--
extra : rebase_source : 7893ff80d10d3f0fd25aabe5c5fbaebe167e89fe
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973