Fixes Thunderbird build bustage related to target-shared.
Investigation into the build issue revealed that this hack is no longer necessary and can be removed. And it's always nice to remove Thunderbird specific code from the build system.
Differential Revision: https://phabricator.services.mozilla.com/D41307
--HG--
extra : moz-landing-system : lando
When a directory, like toolkit/library, builds both a static and a
shared library, and another, like toolkit/library/gtest, depends on the
static part, it currently needs to wait for the shared library to be
finished building, preventing both libraries being built in parallel.
By separating shared libraries to a different target, we allow more
parallelism to the build.
Differential Revision: https://phabricator.services.mozilla.com/D41099
--HG--
extra : moz-landing-system : lando
"confusables" feature:
- Used in 'unicode/uspoof.h' for spoofing detection.
"stringprep" feature:
- Used in 'unicode/usprep.h' for RFC 3454 string preparation.
"unames" feature:
- Used in 'unicode/uchar.h' for `u_charName` to retrieve the name of a Unicode character.
Differential Revision: https://phabricator.services.mozilla.com/D39664
--HG--
extra : moz-landing-system : lando
This gives a nicer error when a sanctioned unit identifier isn't supported by
the current ICU.
Differential Revision: https://phabricator.services.mozilla.com/D38337
--HG--
extra : moz-landing-system : lando
We needed these rules and bits for the QT widget port, but there's no
longer a QT port in the tree, so we might as well remove them.
Differential Revision: https://phabricator.services.mozilla.com/D38886
--HG--
extra : moz-landing-system : lando
Actually we set _DEPEND_CFLAGS to both host and target compiler. But if host and target are different compiler type, we may pass invalid option.
Differential Revision: https://phabricator.services.mozilla.com/D38457
--HG--
extra : moz-landing-system : lando
We don't need to run binary checks on the instrumentation builds, only the final optimized build.
Differential Revision: https://phabricator.services.mozilla.com/D38382
--HG--
extra : moz-landing-system : lando
At the same time, make things a little more tangible in the tiers setup
in baseconfig.mk.
Differential Revision: https://phabricator.services.mozilla.com/D37942
--HG--
extra : moz-landing-system : lando
- Add NumberFormatterSkeleton as a helper class to construct a number formatter
skeleton. When the "Intl.NumberFormat Unified API" proposal gets implemented
a more feature-rich class may be necessary.
- In addition to a UNumberFormatter instance, NumberFormatObject now also
stores a UFormattedNumber instance. This avoids a performance regression
compared to creating a new UFormattedNumber object each time a number gets
formatted. (In micro-benchmarks 20% regressions were seen, with a cached
UFormattedNumber the same micro-benchmarks even improved by ~33%.)
- Add accessors for reserved slot values to NumberFormatObject to improve
readibility.
Differential Revision: https://phabricator.services.mozilla.com/D27083
--HG--
extra : moz-landing-system : lando
- The new formatted-value API is still draft-only, so extra U_HIDE_DRAFT_API guards
are currently needed.
- Also moves steps 4-5 of PartitionRelativeTimePattern to native code to reduce code
duplication.
Differential Revision: https://phabricator.services.mozilla.com/D26719
--HG--
extra : moz-landing-system : lando
- The new formatted-value API is still draft-only, so extra U_HIDE_DRAFT_API guards
are currently needed.
- Also moves steps 4-5 of PartitionRelativeTimePattern to native code to reduce code
duplication.
Differential Revision: https://phabricator.services.mozilla.com/D26719
--HG--
extra : moz-landing-system : lando
The hand-written assembly for libffi on aarch64/windows doesn't emit
unwind information. If we ever tried to unwind through these functions,
they'd look like leaf functions, which is decidedly not true and would
cause great pain.
For whatever reason, the original aarch64 libffi functions used
x21/x22/x23/x24 as their (callee-saved) scratch registers. This
convention works on windows as well, but the unwind information on
windows mandates that we start saving callee-saved registers starting
from x19, rather than x21. Rather than rewriting the assembly to use
x19/x20 instead of x21/x22, which would be a large change, we chose
instead to simply save/restore extra registers in the prolog/epilog.
This change does make the stack frame sizes slightly bigger, but an
extra 16 bytes in libffi stack frames should not matter.
The `-TC` change is necessary to make the compiler play nicely with .asm
file suffixes.
Differential Revision: https://phabricator.services.mozilla.com/D35714
--HG--
extra : moz-landing-system : lando
The condition that enabled ELOG to do something has been broken since
bug 279212 landed two years ago, because MAKEFLAGS doesn't contain the
dash for flags, so looking for "-s" never did anything.
Bug 1560527 changed the condition to !BUILD_VERBOSE_LOG, which as of the
previous commit, does work. This would restore the old behavior, at the
expense of build time, since it involves wrapping in a shell script,
which is not necessarily desirable (and hasn't been done for two years
now)
Differential Revision: https://phabricator.services.mozilla.com/D35967
--HG--
extra : moz-landing-system : lando
Bug 1560527 was not supposed to change verbosity for mach build, but it
turns out it did, because the ifeq it copied from one place to another
was wrong in the first place.
While here, replace a ifeq that did work with the now equivalent
BUILD_VERBOSE_LOG.
Differential Revision: https://phabricator.services.mozilla.com/D35966
--HG--
extra : moz-landing-system : lando
Windows 1-tier PGO builds only partially clobber between the
profile-generate and profile-use stages, so that exports/installed files
don't have to be reprocessed. Unfortunately we can't skip the install
manifests in 3-tier PGO because the profile-generate build happens on a
different machine, so we have to differentiate between 1-tier and 3-tier
PGO builds. A new variable, MOZ_1TIER_PGO, is used for this purpose.
Eventually this logic can be cleaned up in bug 1557788 once all PGO
builds use the 3-tier model.
Differential Revision: https://phabricator.services.mozilla.com/D34802
--HG--
extra : moz-landing-system : lando
When we converted our libffi assembly preprocessing to use
`GENERATED_FILES`, we translated `sed 's%/F[dpa][^ ]*%%g'` to use the Python
regular expression `'F[dpa][^ ]*'`. Note that we missed the leading `/` in
the sed expression; omitting that leading slash causes no end of trouble if
you have particular expressions in your assembly file, such as
"FastFailCode". (I'm a little surprised this hasn't bitten us yet.)
The straightfoward fix is to add the leading slash.
But wait, the rabbit hole goes deeper. The actual bit from libffi's
`msvcc.sh` that this was trying to translate was:
```
echo "$cl -nologo -EP $includes $defines $src > $ppsrc"
"$cl" -nologo -EP $includes $defines $src > $ppsrc || exit $?
output="$(echo $output | sed 's%/F[dpa][^ ]*%%g')"
args="-nologo $safeseh $single $output $ppsrc"
echo "$ml $args"
eval "\"$ml\" $args"
result=$?
```
Note that the sed expression is operating on `$output`, which is a
completely *separate* thing from the output from the result of
preprocessing. In `msvcc.sh`, `$output` is actually some arguments that are
supposed to be passed to the assembler, per the above and the only place in
the script that sets `$output` to a non-trivial value:
```
-o)
outdir="$(dirname $2)"
base="$(basename $2|sed 's/\.[^.]*//g')"
if [ -n "$single" ]; then
output="-Fo$2"
else
output="-Fe$2"
fi
if [ -n "$assembly" ]; then
args="$args $output"
else
args="$args $output -Fd$outdir/$base -Fp$outdir/$base -Fa$outdir/$base"
fi
```
Presumably the sed expression is attempting to remove `-Fd` and friends from
`$args` instead of `$output`, but failing badly at doing so.
In any event, the regex substitution the script is doing is unnecessary and,
with the current code, actively harmful. Let's remove the regular
expression substitution entirely.
Differential Revision: https://phabricator.services.mozilla.com/D35705
--HG--
extra : moz-landing-system : lando
This makes running without mach more consistent. e.g. running
`make -C $objdir/toolkit/library/rust target` makes the cargo log
verbose, and adding `-s` makes it less verbose.
Differential Revision: https://phabricator.services.mozilla.com/D35521
--HG--
extra : moz-landing-system : lando
When the `MOZ_RUST_TIER` environment variable is set, we enable a separate
tier that builds rust code only. This is useful to measure build times for
rust code separately from other compilations.
Differential Revision: https://phabricator.services.mozilla.com/D35501
--HG--
extra : moz-landing-system : lando
When enabling neon (--with-fpu=neon, or when the C++ compiler defaults
to use neon), we pass +neon as a target feature to the rust compiler.
That enables neon in rust, which is the default with the
thumbv7neon-linux-gnueabihf rust target, but not the default for the
armv7-unknown-linux-gnueabihf rust target.
ARM processors may have various different FPUs, with different number of
registers. On ARMv7, there are FPUs with 16 registers and FPUs with 32
registers. NEON requires 32 registers.
Because the common denominator for ARMv7 is 16 registers, the
armv7-unknown-linux-gnueabihf rust target defaults to 16 registers,
although by enabling neon, we're guaranteed the processor will have 32.
But while the rust compiler keeps limited to 16 registers, it also hits
a wall while compiling the hyper crate, where it finds it doesn't have
enough registers (which in itself can be considered a bug).
Since enabling neon means there are 32 registers available, it makes
sense to tell the compiler to lift the restricted use of FPU registers,
and that's what the `-d16` target feature does.
That's the default for the thumbv7neon-linux-gnueabihf rust target, so
nothing is changed, there, and fixes things for the
armv7-unknown-linux-gnueabihf rust target.
Differential Revision: https://phabricator.services.mozilla.com/D33907
--HG--
extra : moz-landing-system : lando
There is a big difference between generated source files that are built
directly, and those that are only included.
In the latter case, the build system won't know the files that does the
including depends on the generated source. So those sources do need to
be built during the export tier.
But in the former case, the build system has all the dependency
information it needs, and, while these generated sources are currently
built as part of the export tier, they don't actually need to be. We're
going to change that, and in preparation, we rename included files so as
to be more clearly identified.
Differential Revision: https://phabricator.services.mozilla.com/D33770
--HG--
extra : moz-landing-system : lando
This changes check_spidermonkey_style.py to account for Zydis and
makes the spidermonkey moz.build aware of the one in zydis.
Differential Revision: https://phabricator.services.mozilla.com/D27850
--HG--
extra : rebase_source : 69f5f37eab2e8bf0c5a55bbffcab894a3a1fe023
This follows the model set down for EME artifacts:
- a new tier is added that uses a new Python build action to fetch and
artifacts
- the action unpacks the fetched artifacts and moves specific inputs
into places expected by the build and packager
- in automation, MOZ_ARTIFACT_TASK* is used to ensure the artifacts
come from the correct tasks
In this case, the artifact fetching is done entirely in a new Python
build action that internally uses `mach artifact install --job ...`.
The action also verifies that the fetched artifacts are compatible and
that we're not assembling a fat AAR that is nonsensical. The specific
inputs are not used in the Fennec APK that is produced; they're only
used in the GeckoView AAR that is produced.
The artifact fetching itself required tweaking to fetch only
`target.maven.zip` artifacts and to not unpack them.
The specific inputs used are the native libraries (libs/$ARCH/*.so)
and the architecture-specific preference files ($ARCH/greprefs.js and
defaults/pref/$ARCH/geckoview-prefs.js). None of these inputs are
impacted by l10n.
Differential Revision: https://phabricator.services.mozilla.com/D31572
--HG--
extra : moz-landing-system : lando
We weren't honoring the case where the library features differ from the tests
features (situation which my previous patch does).
We were incorrectly overriding `rust_feature_flags`, which of course ended up
with a working rusttests with my patches, but a bunch of negative leaks :)
Name the test features differently so that they don't affect the regular library
features.
Differential Revision: https://phabricator.services.mozilla.com/D32777
--HG--
extra : moz-landing-system : lando
We're moving to IR-level PGO instrumentation for clang-cl. We've also
moved to using static linker ordering files, which was the primary
application of the previous style of PGO instrumentation. We therefore
we no longer need this code.
Differential Revision: https://phabricator.services.mozilla.com/D31134
--HG--
extra : moz-landing-system : lando
We used to support specifying single Rust files for compilation,
emphasis on "used to".
Differential Revision: https://phabricator.services.mozilla.com/D32314
--HG--
extra : moz-landing-system : lando
This way compilation backends don't all have to figure out the right way
to handle symbol files.
Differential Revision: https://phabricator.services.mozilla.com/D29673
--HG--
extra : moz-landing-system : lando
This will allow us to copy the pdbs for test files into the resulting
test file archive, but doesn't do it automatically.
Bug 1505936 is for copying some of them.
Differential Revision: https://phabricator.services.mozilla.com/D29761
--HG--
extra : moz-landing-system : lando
ICU changes the numbering system of date formats which include an era marker
to "jpanyear". "jpanyear" is a rule-based numbering system and therefore the
RBNF data for the Japanese locale now need to be included.
Differential Revision: https://phabricator.services.mozilla.com/D27340
--HG--
extra : moz-landing-system : lando
We add to `GARBAGE_DIRS` in the toplevel `Makefile.in` because all of
our Rust libraries share a single `CARGO_TARGET_DIR`, located in
topobjdir.
We add to `GARBAGE_DIRS` for Rust programs because Rust programs
currently do not share compilation artifacts with Rust libraries (as our
libraries are built with `panic=abort` and our programs are not, sharing
compilation artifacts between the two is a non-starter).
Differential Revision: https://phabricator.services.mozilla.com/D26762
--HG--
extra : moz-landing-system : lando
Summary:
- ICU no longer supports removing resource files manually, instead the new data
filter builder needs to be used.
- This includes test data, which also must be preserved in ICU 64.
- umutex.h contains an implicit call to `new` in ICU64 which needs to be allowed
in check_vanilla_allocations.py.
- Drive-by: Make ICU with multiple jobs for faster rebuilds.
Reviewers: jwalden
Reviewed By: jwalden
Bug #: 1533481
Differential Revision: https://phabricator.services.mozilla.com/D25264
--HG--
extra : rebase_source : 9fde775ee9b189c84a29f69f11ebd955f0030b38
Bug 1533425 makes Gecko try to load from $ARCH/greprefs.js, etc on
Android. This patch teaches the packager to put preferences into
those architecture-specific locations for that code to find.
Differential Revision: https://phabricator.services.mozilla.com/D24984
--HG--
extra : moz-landing-system : lando
And change the shell to use JS_InitWithFailureDiagnostic instead of plain
JS_Init, so any ICU data loading errors will be printed to stderr instead of
simply exiting the application.
Differential Revision: https://phabricator.services.mozilla.com/D23133
--HG--
extra : moz-landing-system : lando
The current setup uses different ways for different platforms, with
different workarounds, even using extra configuration items for Windows.
Now that there can't be a difference between the host per the build
system and the host per rust, we can get rid of those configuration
items, and use a more common infrastructure.
We cannot, however, avoid using wrapper scripts, because per-target rust
link-arg flags don't work up great.
The downside is that multiplies the number of wrappers, as we now have
to have a different one for host and target, and then we have .bat files
and shell scripts for, respectively, Windows hosts, and other hosts.
Depends on D24321
Differential Revision: https://phabricator.services.mozilla.com/D24322
--HG--
extra : moz-landing-system : lando
While the substitution pattern is kind of awful in make, it will allow
to more straightforwardly deal with the difference between target and
host.
Differential Revision: https://phabricator.services.mozilla.com/D24321
--HG--
extra : moz-landing-system : lando
The current setup uses different ways for different platforms, with
different workarounds, even using extra configuration items for Windows.
Now that there can't be a difference between the host per the build
system and the host per rust, we can get rid of those configuration
items, and use a more common infrastructure.
We cannot, however, avoid using wrapper scripts, because per-target rust
link-arg flags don't work up great.
The downside is that multiplies the number of wrappers, as we now have
to have a different one for host and target, and then we have .bat files
and shell scripts for, respectively, Windows hosts, and other hosts.
Depends on D24321
Differential Revision: https://phabricator.services.mozilla.com/D24322
--HG--
extra : moz-landing-system : lando
While the substitution pattern is kind of awful in make, it will allow
to more straightforwardly deal with the difference between target and
host.
Differential Revision: https://phabricator.services.mozilla.com/D24321
--HG--
extra : moz-landing-system : lando
This is being changed in Firefox's build config rather than NSPR's
to avoid possibly introducing regressions into other NSPR users due
to bugs in MacOS's poll, such as the POLLPRI issue addressed in the
previous patch. (There is also a known bug when calling poll() with
zero descriptors, but PR_Poll already has code to call PR_Sleep instead
in that case.)
Depends on D21321
Differential Revision: https://phabricator.services.mozilla.com/D21322
--HG--
extra : moz-landing-system : lando
On one-go MOZ_PGO builds, it's generally not wanted to do LTO during the
profile-generate phase. And the build system doesn't really support
different build options between both phases in this case, so we relied
on MOZ_PROFILE_GENERATE to disable the LTO flags.
However, in standalone profile-generate builds, if --enable-lto is
passed explicitly, the build should respect that choice.
So instead of checking MOZ_PROFILE_GENERATE to disable the LTO flags,
we disable them when MOZ_LTO is not set, and we force it to be disabled
during the profile-generate phase of one-go MOZ_PGO builds.
Differential Revision: https://phabricator.services.mozilla.com/D21659
--HG--
extra : moz-landing-system : lando
This patch adds detection for when icecream is in use to build telemetry.
icecream is commonly enabled in two ways: by either setting CC/CXX to point
to icecream's cc/c++ symlinks, or by setting adding
mk_add_options 'export CCACHE_PREFIX=icecc' to a mozconfig when also using
ccache. For the former, this patch adds a simple configure check to see
if CXX is a symlink to a file named 'icecc'. For the latter this patch adds
CCACHE_PREFIX as a configure subst to capture the value.
We don't currently have a facility for writing telemetry tests that depend on
configure values. Local manual testing shows that it does work as expected.
Differential Revision: https://phabricator.services.mozilla.com/D18138
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
While this isn't related to the bug, since we're going to touch the
cargo compiler flags, we might as well do this too.
It wasn't previously reliable to pass those flags down because what
cargo uses as target for build scripts and procedural macros is
determined by the rust host, which was not necessarily the same as the
build system host. But as of bug 1523143, they are always the same.
Differential Revision: https://phabricator.services.mozilla.com/D18280
--HG--
extra : moz-landing-system : lando
Now that Make invokes cargo without going through an msys shell,
environment variables are going to be preserved properly, and we can now
"safely" pass the compiler-related variables down to cargo on Windows.
This makes rust target builds use the expected compiler and flags,
instead of the cc-rs crate guessing, picking cl.exe, and using the wrong
one, with the build later failing when linking it all together because
one of the objects is not for the right target.
Interestingly, the lmdb code is today built for the wrong target on
aarch64, but somehow, it doesn't break the build on automation,
presumably because the lmdb code is actually dead code, and the linker
eliminates the object as unused, masking the problem.
Depends on D18186
Differential Revision: https://phabricator.services.mozilla.com/D18187
--HG--
extra : moz-landing-system : lando
Double quotes on a command line forces Make to use a msys shell when
invoking the command. Single quotes don't have this effect. This is the
last bit that prevented Make from invoking cargo directly on Windows.
Depends on D18184
Differential Revision: https://phabricator.services.mozilla.com/D18185
--HG--
extra : moz-landing-system : lando
These require some awkward setup to keep things working on
non-cross-compiles on non-Windows, but we'll change that shortly in a
later bug.
Depends on D18183
Differential Revision: https://phabricator.services.mozilla.com/D18184
--HG--
extra : moz-landing-system : lando
This is a drive-by change, allowing to keep the
force-cargo-library-build recipe more like the others.
Depends on D18181
Differential Revision: https://phabricator.services.mozilla.com/D18182
--HG--
extra : moz-landing-system : lando
Nathan Froyd
Rob Lemley
Mike Hommey
André Bargull
Makoto Kato
Tom Ritter
Eric Rahm
Adam Gashlin
Mihai Alexandru Michis
Narcis Beleuzu
ffxbld
Justin Wood
Gijs Kruitbosch
Andreea Pavel
Mike Shal
Logan Smyth
Lars T Hansen
Nick Alexander
Ehsan Akhgari
Emilio Cobos Álvarez
Justin Wood
Josh Matthews
Sylvestre Ledru
Henri Sivonen
Petr Sumbera
Jed Davis
Noemi Erli
Dorel Luca
Robert Helmer
David Major
Ted Mielczarek
Jeff Gilbert
Matthew Gaudet
Andy Wingo