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.
rlibs are going to be less important once we start building with cargo:
the focus will move to crates instead, so that's what we should call the
moz.build object.
Through an oversight, we listed librul.a twice when linking libxul: once
as part of the "objects" we were linking, and once as a static library.
This duplication is unnecessary and would cause problems later when we
try to generate librul.a via cargo, as cargo will put it someplace
different from where we expect and the two names will conflict. Let's
have rules.mk be the single source of truth for how librul.a is named,
and then the code to link libxul can simply refer to that name.
Every gfxPrefs::PrefTemplate template declares its own virtual function
overrides for functions declared in gfxPrefs::Pref. The compiler must
therefore create separate copies of each of these virtual functions when
it instantiates PrefTemplate. Since several of these virtual functions
only depend on the template parameter T, the type of the pref, many
instantiations of the functions are identical. The duplicate functions
would normally be merged by identical code folding performed in the
linker, but since these are virtual functions and therefore have their
addresses taken (to be stored in the class's vtable), the linker (at
least for the settings we use for identical code folding) cannot fold
duplicated functions together.
Therefore, we have to do the de-duplication ourselves, by creating an
intermediate templated base class that only depends on the type of the
pref. With this class, only three copies of each virtual function will
be created (one each for bools, floats, and ints). We sneak in
GetLiveValue() into this base class for another small codesize win, even
though it's not a virtual function.
Before Firefox 49.0 there is no processId property available. Given that Firefox ui update tests
have to use the Marionette version from the post build also for the pre build, we currently fail
during in_app restarts for Firefox 48.0 and below.
MozReview-Commit-ID: ILG7JLg0dcS
Sebastian Hengst
Nathan Froyd
aselagea@mozilla.com
Carsten "Tomcat" Book
Tom Schuster
Nicolas B. Pierron
Henrik Skupin
Neil Deakin
Matt Woodrow
Iris Hsiao
cku
Mason Chang