Extracted from the H264 codec and using the stagefright one.
MozReview-Commit-ID: ENjsDvB9MYp
--HG--
extra : rebase_source : 293d8e184cc7b326e6b84d038fd98ff94703f31e
Extracted from the H264 codec and using the stagefright one.
MozReview-Commit-ID: ENjsDvB9MYp
--HG--
extra : rebase_source : 51b92215622df8cdcb65453013ab8022923dd9e8
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.
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
Make Cargo.toml, build.rs and standard cargo source package
layout available in-tree to facilitate testing cargo-driven
builds of rust code.
Update the moz.build script to build using plain rustc as
before, but referencing the new source location.
MozReview-Commit-ID: 11zuebic9tU
--HG--
extra : rebase_source : 1cb71896ae5dd33d1237ca04ec27da60b2256dad
If we can get this to work it will be less confusing, I think.
Byteorder has to be in a subdir while we're treating it as a mod.
We may have to add yet another directory when we have crate support
but until then all the rust code is at least self-contained..
--HG--
rename : media/libstagefright/binding/byteorder/mod.rs => media/libstagefright/binding/mp4parse/byteorder/mod.rs
rename : media/libstagefright/binding/byteorder/new.rs => media/libstagefright/binding/mp4parse/byteorder/new.rs
rename : media/libstagefright/binding/capi.rs => media/libstagefright/binding/mp4parse/capi.rs
rename : media/libstagefright/binding/MP4Metadata.rs => media/libstagefright/binding/mp4parse/lib.rs
DONTBUILD because it only changes comments.
This will hopefully prevent confusion like that in bug 1215903.
--HG--
extra : rebase_source : f0a601d77b5f42b4fbe090693234f934e3becc42
Even though we compile C code as C99, we used to need
-Wdeclaration-after-statement because MSVC didn't allow declarations after
statements.
However, Visual Studio 2013 added support, so we can now merrily mix
declarations and statements everywhere. Hooray.
--HG--
extra : rebase_source : 00a89fed733008785429827408a0c6c466971080
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