When cross-compiling on Windows for e.g. Android, at the moment, we
currently pass -DUNICODE to target C compilations that happen through
Rust because of a erroneous condition in the Makefile. This fixes it.
Differential Revision: https://phabricator.services.mozilla.com/D195069
Today adding a new ABIFunctionType requires:
1. Adding a new option to the enum
2. Updating all the simulators to handle redirects of this type
(1) is easy after we added some constexpr code for constructing
these types.
(2) is really painful, because it requires building on multiple
platforms to test, and requires knowledge of all ABI's to get
details about registers/stack/etc correct.
This patch adds a build-time step which will generate (1) and (2)
from a declarative YAML file.
The interesting piece is (2) which has to understand the ABI
rules and simulator data structures for generating the code.
It's tricky code, but think it's easier to maintain and prove
correct in one place vs. in a big simulator switch. A data point
for this is that implementing this uncovered a few cases where
our hand-written code was technically incorrect (although practically
not an issue yet).
Depends on D193111
Differential Revision: https://phabricator.services.mozilla.com/D193112
I plan on re-using and generalizing the intrinsics code for supporting
the new 'builtin modules' concept as required by the js-string-builtins
proposal. First step is a rename. No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D193110
In the build, we have a few cases of things that have the same name,
but they happen in different directories. While disambiguating them
in the profile itself might not be super important (although it may turn
out to be, but let's assume it's not that important for now because I
also don't really want to add the directory everywhere), not
disambiguating them while tracking the markers makes it so that when it
happens that ambiguous things are running in parallel, the profile ends
up with wrong data for the corresponding markers.
Differential Revision: https://phabricator.services.mozilla.com/D192044
There are a number of occasions where changes to rust code doesn't
trigger cargo to run on an incremental build. In most cases, these
changes are accompanied with a change in Cargo.lock, so let's make cargo
run every time Cargo.lock changes.
Differential Revision: https://phabricator.services.mozilla.com/D192018
$? will only pass the dependencies that have triggered the command to be
called, which will save some work in rebuild_check. However, since
rebuild_check does the difference between removed and modified files,
it still needs to keep checking files.
But, the real reason we need this check is that gkrust.d can have
dependencies with spaces in them, and Make special variables like $^ or
$? don't handle those nicely, and while those files with spaces in
them are most likely unchanged (in most cases, they are going to be
files from the Windows SDK), they end up always reported as the cause
for rebuilds when setting REBUILD_CHECK. $? is more likely not to
contain files with spaces.
Differential Revision: https://phabricator.services.mozilla.com/D191381
Because the force-cargo-* rules don't have actual dependencies, the
REPORT_BUILD call can't usefully report why cargo is invoked when
setting REBUILD_CHECK.
This also has the side effect of making the non-verbose output nicer
(containing the actual built file rather than force-cargo-*)
Differential Revision: https://phabricator.services.mozilla.com/D191380
There are subtle differences in the two implementations that actually
make the variant for RUST_PROGRAMS not work currently:
- there is a %.h leftover from bug 1855623
- there is a missing $(basename) when trying to find the .d file,
preventing it from being found.
With a common rule, we avoid such subtle differences, and that also
allows to further implement fixes without missing one of the cases.
This will also allow to add the same trick to other rules, which should
already have it.
Differential Revision: https://phabricator.services.mozilla.com/D191378
Back when this was added, there was an incentive to try to build
gkrust-gtest before gkrust so that libxul-gtest could have a chance
to link and be dumpsymbol'ed while gkrust compiles.
While we may still want that to happen to some degree, the way it's done
right now, with how things evolved over the years, ends up being
counterproductive and ends up delaying all the rust compiles entirely.
We'll deal with improving the overall ordering of builds in bug 1651293.
(This only affects CI)
Differential Revision: https://phabricator.services.mozilla.com/D192015
This change introduces the possibility for more interdependencies being
recorded automatically, but making this work reliably more generally
we'll probably need more work, so at the moment, just make it work for
wasm2c.
Differential Revision: https://phabricator.services.mozilla.com/D191925
At the top-level, what we currently have is something akin to:
export: some deps
echo BUILDSTATUS TIER_START export
make recurse_export
...
In practice, what this means is that `some` and `deps` are built outside
the export tier/phase.
Since recurse_export is itself a recipe with dependencies, we can "just"
move `some` and `deps` to become dependencies of recurse_export instead.
But since in non top-level directories, recurse_export is not a thing,
we still need to keep the dependencies on export there.
Unfortunately, we have one instance of something built during
recurse_export that relied on its undeclared/undeclarable dependencies
being built before recurse_export, so we need to accomodate for that.
Also, for some reason, recurse_pre-export was a two-colons recipe, while
the other recurse_* recipes were single-colon, so fix that.
Come to think of it, the same probably applies to misc and libs, which
this would mechanically fix alongside.
Incidentally, this also makes those things that ran before recurse_* run
in parallel of the other things that run during recurse_*.
Differential Revision: https://phabricator.services.mozilla.com/D191913
$? will only pass the dependencies that have triggered the command to be
called, which will save some work in rebuild_check. However, since
rebuild_check does the difference between removed and modified files,
it still needs to keep checking files.
But, the real reason we need this check is that gkrust.d can have
dependencies with spaces in them, and Make special variables like $^ or
$? don't handle those nicely, and while those files with spaces in
them are most likely unchanged (in most cases, they are going to be
files from the Windows SDK), they end up always reported as the cause
for rebuilds when setting REBUILD_CHECK. $? is more likely not to
contain files with spaces.
Differential Revision: https://phabricator.services.mozilla.com/D191381
Because the force-cargo-* rules don't have actual dependencies, the
REPORT_BUILD call can't usefully report why cargo is invoked when
setting REBUILD_CHECK.
This also has the side effect of making the non-verbose output nicer
(containing the actual built file rather than force-cargo-*)
Differential Revision: https://phabricator.services.mozilla.com/D191380
There are subtle differences in the two implementations that actually
make the variant for RUST_PROGRAMS not work currently:
- there is a %.h leftover from bug 1855623
- there is a missing $(basename) when trying to find the .d file,
preventing it from being found.
With a common rule, we avoid such subtle differences, and that also
allows to further implement fixes without missing one of the cases.
This will also allow to add the same trick to other rules, which should
already have it.
Differential Revision: https://phabricator.services.mozilla.com/D191378
Updates the ICU patch "double-conversion.diff" to only use the in-tree copy of
double-conversion when building Firefox/SpiderMonkey. Standalone ICU builds
instead use the ICU copy of double-conversion. Standalone ICU builds happen
when running "intl/icu_sources_data.py" and when converting the in-tree
little-endian ICU data file to the big-endian format.
`JS_HAS_INTL_API` is used to detect how ICU is built: When building ICU as part
of Firefox/SpiderMonkey, `JS_HAS_INTL_API` is guaranteed to be set, whereas in
standalone ICU builds `JS_HAS_INTL_API` isn't defined.
After applying the updated "double-conversion.diff" patch, ICU was reimported
to restore the previously deleted double-conversion sources files from ICU.
Depends on D190791
Differential Revision: https://phabricator.services.mozilla.com/D190792
As of now, cargo only supports HTML timings output. There is an unstable
flag for a json output, but we can't use that because it requires a
nightly cargo. So we do our best effort to get the data we need off the
HTML, but since the exact details of the format of that file are not
set in stone, we also prevent any error from being unhandled. It's
better not to have the data than break the build.
Differential Revision: https://phabricator.services.mozilla.com/D190884
- avoid using py_action with addprefix (process_install_manifest calls)
- use a foreach make loop instead of a shell script for loop (toolkit/components/telemetry)
- pass the directory in which MAKE_PACKAGE should run as an argument instead of changing the directory before calling the macro.
Differential Revision: https://phabricator.services.mozilla.com/D190513
This patch contains three changes:
1. a local version of glb.iglob in vendor_manifest.py that always
matches hidden files for '**'. I've tested it on Python 3.5 up to
3.12 and it works as expected.
2. a cleanup of many moz.yaml files that got convluted because of the
previous behavior of '**'
3. removal of a few useless files that are now caught by the '**'
globbing.
Differential Revision: https://phabricator.services.mozilla.com/D190195
This extends bug 1831334 to apply to any kind of dependency, not only
C header files, and we normalize paths separator on Windows, because
cargo/rustc emits paths with a mix of forward and backwards slashes, and
make doesn't like the latter.
Differential Revision: https://phabricator.services.mozilla.com/D189456
Sylvestre Ledru
Mike Hommey
Ryan Hunt
Mozilla Releng Treescript
Noemi Erli
Rob Lemley
André Bargull
Narcis Beleuzu
Cosmin Sabou
Julien Cristau
stransky
Florian Quèze
Sandor Molnar
serge-sans-paille