To not merge the en-US language pack, the merge-% steps are in
a conditional function that disables that for en-US. Using a function
here as that's easier than a shell if in the merge rule, and
Makefile conditionals don't get evaluated late enough.
To liberate the l10n builds from settings in the automation,
we move the patch logic from LOCALE_MERGEDIR to REAL_LOCALE_MERGEDIR.
To determine strongly when we're in a repack or building a langpack,
the trick here is to
export IS_LANGUAGE_REPACK
in l10n.mk, and only set that to true in the entry-point rules.
Now, we can use that value in config.mk to define the l10n-specific
rules.
I did the same thing for langpack-%, which allows us to disable
the crashreporter files for language packs, for example.
With that,
make installers-de
just works, if you have localizations checked out.
For a while, we might run l10n-merge twice in automation, but it's really not
optional, so let's just make sure we run it.
MozReview-Commit-ID: 3nr33CKxkBQ
--HG--
extra : rebase_source : 0605a4adba018fa4b85d563cdafba80b0533bc91
cargo 1.19, and later cargo 1.20/rustc 1.19 gained support for the make
jobserver. But that doesn't work unless make passes the jobserver file
descriptors down to subprocesses, which it only does when there is a +
prefixing commands.
--HG--
extra : rebase_source : a00ffb7edb358243ac7b9469941ec6fb5ad84885
This is similar to bug 1301751, where something in rust seems to trigger errors
running dsymutil to generate debug symbols in OSX. We can set debuginfo=1 for
these builds as a temporary workaround for now, while we work on a more
permanent solution in rust and/or dsymutil. debuginfo=1 still gives us enough
info for stack traces, although without line info. debuginfo=2 would be useful
for debugging, but is irrelevant to crash reports.
MozReview-Commit-ID: DdA00GzVfWg
--HG--
extra : amend_source : 47d3573042098194a07f9b473e4a02c86a1eba7c
MOZ_REPLACE_MALLOC_LINKAGE was added back when there were problems with
getting weak references working properly for replace-malloc.
Versions of OSX < 10.6 needed flat namespace, but aren't supported
anymore.
Versions of Xcode < 4.5 required flat namespace + a dummy library in
order to produce proper weak references. There is virtually nobody still
building with such an ancient toolchain.
Keeping those around doesn't /really/ hurt, except recent versions of
Xcode don't expose dyldinfo in /usr/bin, used for the configure test.
Consequently, MOZ_REPLACE_MALLOC_LINKAGE ended up being set to use the
dummy library setup, which, by using flat namespace, now causes harm in
bug 1356701, causing bug 1378332.
--HG--
extra : rebase_source : e3edc1f2cf905943c33fafeb631f2f88fc87167e
Cargo recently introduced the `cargo check` command for shortening the
edit-compile cycle when working on large programs. Since we don't
really support invoking `cargo` directly, let's wire up this command to
`mach`. Gecko developers can then `mach cargo check` to ensure their
changes typecheck.
All the machinery we set up for `cargo build` is equally useful for
other commands, such as `cargo check`. Let's refactor things so that
it's easy to reuse said machinery for `cargo check`.
We currently only honor LIB_IS_C_ONLY for cases where we set a
LIBRARY (and, implicitly, REAL_LIBRARY) and FORCE_SHARED_LIB. For many
libraries, such as the libraries from NSS, we never set LIBRARY, which
leads to not setting REAL_LIBRARY, which leads to not honoring
LIB_IS_C_ONLY. This practice has not been harmful thus far (except
perhaps linking in more things than necessary to our NSS shared
libraries), but on some platforms, linking with the C++ compiler will
drag in more things than we would like.
Consulting LIBRARY first should not be necessary; checking
FORCE_SHARED_LIB should be enough to tell us if we're building a shared
library for the purposes of honoring LIB_IS_C_ONLY.
We can avoid the symbol visibility problem by putting
sanitizer/asan_interface.h in the config/system-headers.
--HG--
extra : rebase_source : bc81a81ef8970c3544febf06631740208583c7fa
Stable Rust currently has logic similar to the following for finding the
linker on Windows:
if VCINSTALLDIR in os.env:
search for things in PATH
if found, return, otherwise fallthrough
look for MSVC installations of various kinds
For our current MozillaBuild setup where we clear out PATH prior to
invoking Cargo, this works: even though VCINSTALLDIR is set and we
(unsuccessfully) search through an empty PATH, we'll still fallback to
looking for MSVC installations.
Beta Rust has altered this search strategy:
if VCINSTALLDIR in os.env:
search for things in PATH
return the result of the search, regardless of success
look for MSVC installations of various kinds
Note that in the above logic, if VCINSTALLDIR is set, we are only going
to try looking in PATH for an appropriate linker. Since PATH is empty
in our current MozillaBuild setup, beta Rust will therefore fail to find
the correct linker. This failure causes numerous problems.
Since Firefox is already trying to "clean" the environment that Cargo is
invoked in, we should work a little bit harder by unsetting VCINSTALLDIR
entirely, and simply force Rust to search for known MSVC installations.
Making this change makes stable and beta Rust behave identically.
(We don't have to worry about this distinction in automation, because
the "cleaning" code is only activated when we detect a MozillaBuild
shell.)
Since we set WINVER=601 after dropping Windows XP support, it is unnecessary to define LOCALE_SNAME. So, we should remove it to remove compiler warning.
MozReview-Commit-ID: EawbHAznXNA
--HG--
extra : histedit_source : d3157300315052048756c22ac2c999523d28679d
Final target Rust programs are currently not picked up and
symlinked/copied to ${objdir}/dist/bin because the RUST_PROGRAMS output
variable is missing from the if-condition.
This change causes Rust binaries from RUST_PROGRAMS to be placed alongside
the other final target programs.
MozReview-Commit-ID: 5OIH1UMmCq2
--HG--
extra : rebase_source : cfcff21e9371b920c895ad27df344008962d7471
These paths can contain spaces, particularly if they point into
${HOME}/.mozbuild on Windows. If people are bold enough to use the
Windows packages from llvm.org, the LLVM packages are installed by
default into C:\Program Files\LLVM, so paths from there would contain
spaces as well.
Procedural macros for rust are compiled as dynamic libraries.
The compiler subsequently loads those libraries at runtime
when it compiles crates which make use of them.
We pass the generic LDFLAGS to our linker wrapper which ensures
cargo links static libraries with the correct flags. However
this also means that any final system dependency libraries
end up linked into the procedural macro dynamic libraries
whether they use them or not.
When building on macOS 10.7, this causes a SIGTRAP when dlopen
calls CFInitialize for system libraries like Cocoa off the main
thread. We believe this is a macOS bug, reported fixed in macOS 10.9.
https://openradar.appspot.com/7209349
Work around the issue by stripping those libraries and Frameworks
from the linker flags we pass to cargo. We could do a more careful
job of parsing and removing all -framework and -lfoo arguments
inside the linker script, but since this is a temporary issue
while we're using older build machines, I thought just stripping
them once in the build system was simpler.
MozReview-Commit-ID: CGXD8ARvojj
--HG--
extra : rebase_source : 33f28e8fbafb43dbdd257d9162a6e792fca79e51
We're getting an intermittent failure running `hg manifest` in CI. I
have no clue why.
What I do know is that we now have the mozversioncontrol Python package
for containing utility code for interacting with version control. It is
slightly more robust and I'm willing to support it more than I am
check_utils.py.
This commit adds a new API to our abstract repository class to obtain the
files in the working directory by querying version control.
Since I suspect cwd was coming into play in automation, I've also
added a utility function to mozversioncontrol to attempt to find
a version control checkout from the current working directory. It
simply traces ancestor paths looking for a .hg or .git directory.
Finally, I've ported all callers of the now-deleted API to the new
one. The old code had some "../.." paths in it, meaning it only
worked when cwd was just right. Since we resolve the absolute path
to the checkout and store it on the repo object, I've updated the
code so it should work no matter what cwd is as long as a repo can
be found. I'm not 100% confident I found all consumers assuming cwd.
But it's a start.
I'm not 100% confident this will fix the intermittent issues in CI. But
at least we should get a better error message and at least we'll be
running less hacky code.
MozReview-Commit-ID: AmCraHXcTEX
--HG--
extra : rebase_source : 815ae369776577ad374333920fd645d412a55148
gfx/skia/skia/src/core/SkCpu.cpp might use sys/auxv.h to detect CPU feature. So we should add it to system-headers
MozReview-Commit-ID: SijyUYvLgn
--HG--
extra : rebase_source : 0b509c2f5b4f3272578ae511e9c69cf6b0999c42
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
Build system switch for optional inclusion of libaom
for support of the Alliance for Open Media AV1 video
codec.
MozReview-Commit-ID: 2C4o1ogRS9v
--HG--
extra : rebase_source : d4a68f1fc4654895f62a905666f0b75726e20e7f
The Java Addons mechanism never got traction and is not Web Extensions
compatible. Removing it simplifies the product and the build system.
MozReview-Commit-ID: ABUxkqqMISa
--HG--
extra : rebase_source : 346f88882774f072316714cf637a54d771d81a9a
Several years ago, joey starting writing a handful of unit tests for
primitives in our make files. IIRC a lot of the impetus behind this
work was to flush out bugs between GNU make and pymake.
AFAICT the only survivor of these tests today is check_mkdir.py. The
test is a one-off and has been a bit fragile over the years,
contributing technical debt along the way. And as part of removing the
last references to pymake in automation, it is once again showing
itself and failing in a way that has to do with the way the test
is written and not an issue with the code it is testing. Enough is
enough. This commit removes the test and eliminates the technical
debt. I don't think it will be missed.
MozReview-Commit-ID: 3OzurtFbcyD
--HG--
extra : rebase_source : 6d3cf6121c90e9c47948862b8c4117bb1d3e5afd
Axel Hecht
ffxbld
Robert Strong
Sylvestre Ledru
Tom Prince
Mike Hommey
Mike Shal
Nathan Froyd
Nicholas Nethercote
Nicolas B. Pierron
André Bargull
Jeff Gilbert
Ted Mielczarek
Chris Manchester
Henri Sivonen
Ryan VanderMeulen
Marco Castelluccio
Petr Sumbera
Makoto Kato
Masatoshi Kimura
Andreas Tolfsen
Ralph Giles
Bruce Sun
Gregory Szorc
Xidorn Quan
Wes Kocher
Iris Hsiao
Jon Coppeard
Sebastian Hengst
Lee Salzman
Nick Alexander