Doing this gets us all of the benefits that we want from Cargo
workspaces (only compiling artifacts from gkrust-shared one time for
both libraries) without all the hassles that using Cargo workspaces
would require. We don't have to worry about multiple Cargo processes
running simultaneously and racing to write files; Cargo is smart enough
to lock the build directory to serialize access to it.
Now that we use the real geckolib and have all dependencies vendored,
the dummy geckolib is no longer required, so we remove it.
Also, the taskgraph code for testing for Servo's presence always
passes and is no longer needed, so we remove it.
Pushed on a CLOSED TREE because ¯\_(ツ)_/¯
MozReview-Commit-ID: ITAqArK4Bks
--HG--
extra : rebase_source : 5eedb3994b679109246b89b0456dd2a59ef3212b
extra : amend_source : b0c97486ae2b72fd21c7968849735e4189e2e86f
This updates the following third-party dependencies of mozjs_sys:
gcc v0.3.40 -> v0.3.42
libc v0.2.18 -> v0.2.20
libz-sys v1.0.10 -> v1.0.12
pkg-config v0.3.8 -> v0.3.9
Since libc is updated, we also need to update the gkrust lockfiles to use the
new version, because leaving it at 0.2.18 will result in improper vendoring of
the crates (see bug 1336528). None of the other mozjs_sys crates are shared by
gkrust.
MozReview-Commit-ID: 5FHELF8YKD0
--HG--
extra : rebase_source : a6a4d635d4a3b9c2faa23f935c4be59e8588fbbf
I want to get Servo vendored into servo/. The previous plan was to
replace the dummy geckolib with the real deal when the vendoring is
done. Unfortunately, this will require a significant `cargo vendor`
change, which we want to punt on for a bit.
So, this commit moves our dummy geckolib outside of servo/ so we
don't need to `cargo update` or `cargo vendor` when the real servo/
is installed.
The change to toolkit/library/rust/shared/Cargo.toml can be reverted
in the stylo repo to allow it to use the real geckolib.
We also update the taskgraph code for detecting Servo. Previously,
it looked for a file in the possibly-vendored servo/ directory. Once
the vendoring happens, this check will always pass. But without the
real geckolib, the Servo builds will fail. So, we change the check
to look for the real geckolib. This is implemented a bit hackily.
But it will be short-lived until we run `cargo vendor`.
MozReview-Commit-ID: CxGTwy6bK9j
--HG--
rename : servo/ports/geckolib/Cargo.toml => toolkit/library/geckolib/Cargo.toml
rename : servo/ports/geckolib/lib.rs => toolkit/library/geckolib/lib.rs
extra : rebase_source : c0e9c867ae74c4eb124e72dc481fd8dc814e65e7
268fa5f3bc25 grafted an old patch to define --features=servo in
rules.mk. That patch was written before RUST_LIBRARY_FEATURES
existed. This commit fixes it up.
MozReview-Commit-ID: L5atm5CsP8d
--HG--
extra : amend_source : 9362db15a696ebd5871df94afb429d6f828de184
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
Update the vendored third-party dependencies for the mozjs-sys crate.
This picks up recent bug-fixes and reduces noise in unrelated runs
of 'mach vendor'.
The libc crate is also used by the rust url parser.
gcc 0.3.35 -> 0.3.40
libc 0.2.16 -> 0.2.18
libz-sys 1.0.6 -> 1.0.10
MozReview-Commit-ID: 5ri4nOtQQ1n
--HG--
extra : rebase_source : e3bfd2be7f3e615822a9177634dd8545236f0a19
This patch also drops the pretense that rust-url-capi will be used from
outside of c++, or that it will be used outside of mozilla-central,
removing the ifdef __cplusplus code, and including the C++ header
"nsString.h".
MozReview-Commit-ID: BULhHf3DObe
In our current Rust world, we have the following dependency structure:
xul.so --------------------------+
|
xul-gtest.so -+--> xul.a --------+-> gkrust
|
+--> gkrust-gtest
This structure results in link errors with multiply-defined symbols
between gkrust-gtest and gkrust with newer Rust releases when linking
xul-gtest.so. So we have to do something different.
Our new structure is:
xul.so --------------------------+
|
xul-gtest.so -+--> xul.a --------+-> gkrust --+-> gkrust-shared
| |
+--> gkrust-gtest --------------+
and we enforce that a given shared library can only have at most one
Rust library that it depends on. Said Rust library is assumed to
include all significant Rust dependencies of the dependent static
libraries as well. (In the above structure, gkrust is simply a wrapper
around gkrust-shared, so gkrust-gtest doesn't have to include gkrust as
a dependency.)
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
This patch removes the memory usage tracking in the script that wraps the
linking of the xul library. This patch also generalizes the wrapping of the
xul linking process to all platforms.
MozReview-Commit-ID: HyncF3aVwdx
--HG--
extra : rebase_source : 8fb90c896dc57793d1c9d9aa4e8492dec8697e36
Result of running the update script, followed by `cargo update`
in tookit/library/rust/.
MozReview-Commit-ID: LNdvuOqVx9a
--HG--
extra : rebase_source : 70b263d1ba1867b5b2b907530fab4beedc25ae56
For testing purposes it will be useful to be able to trigger crashes in Rust
code. Being able to trigger a panic seems like a good place to start. This
will make it easier to validate improvements in crash reporting.
MozReview-Commit-ID: Bh5rBieLLWW
--HG--
rename : toolkit/crashreporter/test/unit/test_crash_moz_crash.js => toolkit/crashreporter/test/unit/test_crash_rust_panic.js
extra : rebase_source : 7cfc08e62de49de869b97ae96630db573f882f18
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
Result of running the update script and updating gecko's
integration crate for the layout change.
MozReview-Commit-ID: GaIMFKmPmtf
--HG--
extra : rebase_source : 0d3a2f1d211840879e562cb56afcc9ef7e38c730
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.
Run the updated import script to split the in-tree byteorder
code into a separate directory and build it as a dependent crate.
MozReview-Commit-ID: EI5X4icOdmM
--HG--
extra : rebase_source : fa0d4cce8503ede5d2fbefc4d4b78735f2140c33
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.
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
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.
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
This also effectively changes how DMD is enabled from requiring both
replace-malloc initialization and the DMD environment variable to
requiring only the former. The DMD environment variable can still be
used to specify options, but not to disable entirely.
This however doesn't touch all the parts that do enable DMD by setting
the DMD environment variable to 1, so the code to handle this value
is kept.
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
OS_LIBS for libraries that are not part of the gecko tree, EXTRA_LIBS for
libraries, such as NSPR, that are in the tree, but are not handled by
moz.build just yet. Those EXTRA_LIBS may also come from a system library.
However, in cases where the expanded variables are always empty for the
in-tree case, OS_LIBS is used (as for, e.g. MOZ_ZLIB_LIBS). OS_LDFLAGS is
used exclusively for non-library linker flags.
Always pass EXTRA_LIBS before OS_LIBS on linker command lines.
Forbid EXTRA_DSO_LDOPTS, SHARED_LIBRARY_LIBS and LIBS in Makefiles.
This is necessary for plugins when building libxul for GTK+ 3
because libxul will link against GTK+ 3 and some plugins link
against GTK+ 2, but both GTK+ libraries can't be loaded in the
same process. With this change, we have an indirection between
libxul and libgtk, named libmozgtk. plugin-container will
be modified to load libmozgtk2 in order to only have GTK+ 2
in its address space, thus enabling various plugins (e.g. flash)
on GTK+ 3 firefox.
It's just as easy to directly set the preprocessor macro in the moz.build
files. Using this variable doesn't really buy us anything.
This patch also removes unused code from rdf/tests/dsds.
