Linking Rust code against the updatecommon library is not well supported by our build system, but it should be possible. The changes to updatecommon's moz.build will cause updatecommon.lib to be created, which Rust can link against. The build.rs script tells cargo which shared Windows libraries are needed for linking, and where updatecommon.lib can be found. The change to config/recurse.mk enforces the dependency of the update agent on updatecommon, so that we do not attempt to link the agent before updatecommon has been built.
Differential Revision: https://phabricator.services.mozilla.com/D70207
For native sanitizer builds, we currently do not pass the linker flags
to cargo, as they were causing crashes in some build scripts. Without
this, however, the linker is unable to find libstdc++. Instead, do
tell cargo to use the linker wrapper, but omit the problematic flags
from MOZ_CARGO_WRAP_LDFLAGS.
Differential Revision: https://phabricator.services.mozilla.com/D70354
For now this generates just CACHE_IR_OPS and CACHE_IR_SHARED_OPS in CacheIROpsGenerated.h
but the plan is to use this to generate parts of the IR writer and compiler/transpiler
interface. The spewer could also potentially be improved now that each operand has a name
and more precise type.
Generating the IR writer will likely happen incrementally so that will give us
another chance to double check the precise types match what's in the YAML file.
Differential Revision: https://phabricator.services.mozilla.com/D70995
--HG--
extra : moz-landing-system : lando
Most other generated SpiderMonkey files have the 'Generated' suffix so let's
follow that convention.
Differential Revision: https://phabricator.services.mozilla.com/D70993
--HG--
extra : moz-landing-system : lando
They all fail for the same reason: the sanitizer runtime in compiler-rt installs an interceptor for `getsockname` which then contains a call to the real implementation.
Differential Revision: https://phabricator.services.mozilla.com/D70889
--HG--
extra : moz-landing-system : lando
Also enable all config/tests with python3. unit-nsinstall.py was the
last one that didn't pass with python 3.
Switch the test to using @unittest.skipIf and disable the subprocess
test because we purposely broke running nsinstall.py independently with
python 2.
Differential Revision: https://phabricator.services.mozilla.com/D70160
--HG--
extra : moz-landing-system : lando
Since the test goes through all moz.build files disregarding DIRS and
the conditions that may disable directories, in some cases, moz.builds
can fail to be evaluated properly because of missing variables in
config.status. This time (because it's not the first), it's
LLVM_DLLTOOL.
After fixing that, it turns out many of the files/directories pointed to
by Files() directives were removed or moved.
While here, make the test script python3-ready.
Differential Revision: https://phabricator.services.mozilla.com/D70157
--HG--
extra : moz-landing-system : lando
This needs a few adjustments to the autobinscope script because running
binscope currently creates an HTML file in the binscope directory, and
when multiple binscopes run at the same time (which happens during the
build with the changes to run it on all executables and libraries), all
but one fail to open the HTML file for write access.
So add a flag to create that file in a temporary directory.
While here, remove log_file_path, which hasn't been used since
bug 1448306.
Differential Revision: https://phabricator.services.mozilla.com/D67422
--HG--
extra : moz-landing-system : lando
Because most of the recent changes to irregexp were patches I contributed myself, we barely need to change any of the shim code.
The only notable change is the addition of '#define COMPILING_IRREGEXP_FOR_EXTERNAL_EMBEDDER'. This is the solution that Jakob Gruber and I eventually came up with for the question of what to do with awkward V8 code that SM doesn't want. For example, NativeRegExpMacroAssembler::Match (in regexp-macro-assembler.cc) gets down in the muck with the internal details of V8's String implementation. It would be most convenient for SM if that function just didn't exist; we aren't going to use it, and we don't want to have to define a bunch of unused string API gunk in our shim. The answer is to wrap functions we don't need in "#ifndef COMPILING_IRREGEXP_FOR_EXTERNAL_EMBEDDER", which solves our problem and is minimally disruptive upstream.
Depends on D67718
Differential Revision: https://phabricator.services.mozilla.com/D67719
--HG--
extra : moz-landing-system : lando
This needs a few adjustments to the autobinscope script because running
binscope currently creates an HTML file in the binscope directory, and
when multiple binscopes run at the same time (which happens during the
build with the changes to run it on all executables and libraries), all
but one fail to open the HTML file for write access.
So add a flag to create that file in a temporary directory.
While here, remove log_file_path, which hasn't been used since
bug 1448306.
Differential Revision: https://phabricator.services.mozilla.com/D67422
--HG--
extra : moz-landing-system : lando
Dictionary iteration under Python 3 is in an inherently unpredictable order, and while we try to keep DEFINES ordered through the use of OrderedDicts, if at any point we populate DEFINES directly or indirectly while iterating through the contents of a non-ordered dictionary, the order of the DEFINES (and therefore the contents of the output Makefile) will be nondeterministic as well. This patch makes a number of changes to ensure that we only ever populate DEFINES in a deterministic fashion. (Note that in Python 3.7 and later, the built-in dict class actually has deterministic ordering, so these changes are technically only necessary until our minimum Python version becomes 3.7.)
Differential Revision: https://phabricator.services.mozilla.com/D66089
--HG--
extra : moz-landing-system : lando
Dictionary iteration under Python 3 is in an inherently unpredictable order, and while we try to keep DEFINES ordered through the use of OrderedDicts, if at any point we populate DEFINES directly or indirectly while iterating through the contents of a non-ordered dictionary, the order of the DEFINES (and therefore the contents of the output Makefile) will be nondeterministic as well. This patch makes a number of changes to ensure that we only ever populate DEFINES in a deterministic fashion. (Note that in Python 3.7 and later, the built-in dict class actually has deterministic ordering, so these changes are technically only necessary until our minimum Python version becomes 3.7.)
Differential Revision: https://phabricator.services.mozilla.com/D66089
--HG--
extra : moz-landing-system : lando
- Remove the separate option() for MT, because it dates back from when
we needed `MT` not being an absolute path, but that hasn't been true
since bug 1290040.
- Extend what was done in bug 1617794 to MT, although the long term move
is to not rely on MT at all.
- Patch leftovers from bug 1613799.
Differential Revision: https://phabricator.services.mozilla.com/D64712
--HG--
extra : moz-landing-system : lando
Windows programs run via Wine don't like Unix absolute paths (they look
like command line arguments), so we need to use relative paths.
Mingw already run fxc2 via wine, but for some reason it doesn't care
about the Unix absolute paths. genshaders does need some adjustements to
run properly with the real fxc.
Now, on actual Windows, because the temporary directory where
tempfile.NamedTemporaryFile creates files by default is not necessarily
on the same drive as where the command runs from, a relative path can't
be constructed. So we also force the temporary file to be created in the
current (obj) directory.
There is no similar concern for other files because we only go from
objdir to srcdir, and the build system already doesn't support both
being on a separate drive.
While here, flush stdout when the genshared script writes to it, so that
the messages are printed out immediately rather than randomly, later,
after output from subprocesses.
Differential Revision: https://phabricator.services.mozilla.com/D64294
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
This change is a little gross, because we don't totally control where
the statically initialized instances of `RWLock` live, due to its uses
in third-party libraries.
Differential Revision: https://phabricator.services.mozilla.com/D62936
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
- -NOLOGO is used to hide the banner that MSVC displays by default. It's
a no-op with clang-cl, no need to keep it now that we don't support
MSVC.
- -utf-8 is only passed when the compiler is not GCC-ish and not
clang-cl, which used to mean MSVC, but now means no compiler.
Differential Revision: https://phabricator.services.mozilla.com/D62705
--HG--
extra : moz-landing-system : lando
`lucetc` by default will invoke `ld` directly, which is usually not what
we want, particularly when cross-compiling. Instead, let's invoke the
compiler, which will do the hard work of determining the correct linker
to use, and we'll also explicitly specify `LDFLAGS`, since the default
`LDFLAGS` from `lucetc` assume you're invoking the linker directly.
Depends on D62797
Differential Revision: https://phabricator.services.mozilla.com/D62798
--HG--
extra : moz-landing-system : lando
We're going to need this for handling Mac cross compiles correctly.
Depends on D62795
Differential Revision: https://phabricator.services.mozilla.com/D62796
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
By default the Rust compiler will perform a limited kind of ThinLTO on each
crate. For local builds this additional optimization is not worth the
increase in compile time.
Differential Revision: https://phabricator.services.mozilla.com/D61821
--HG--
extra : moz-landing-system : lando
Baby steps. Working towards not using $(MT), let's unsupport what we
currently don't rely on (and in case someone would try to rely on it,
throw an error).
Differential Revision: https://phabricator.services.mozilla.com/D61948
--HG--
extra : moz-landing-system : lando
At the moment, everything we're putting in a wasm sandbox is not
performance-critical, so we don't need PGO. It's also not clear that
PGO would actually work properly with code that's been run through
wasm. Let's leave figuring that out until, at the very least, the wasm
toolchain is a little more mature.
Differential Revision: https://phabricator.services.mozilla.com/D58513
--HG--
extra : moz-landing-system : lando
Turns out we were using the Linux ones. This uses the Windows ones, and
adds _HAS_EXCEPTIONS to the mingw defines so the stl_wrappers behave
correctly.
Differential Revision: https://phabricator.services.mozilla.com/D54530
--HG--
extra : moz-landing-system : lando
Turns out we were using the Linux ones. This uses the Windows ones, and
adds _HAS_EXCEPTIONS to the mingw defines so the stl_wrappers behave
correctly.
Differential Revision: https://phabricator.services.mozilla.com/D54530
--HG--
extra : moz-landing-system : lando
In 1-tier PGO builds that shared the objdir between the instrumented and
profile-use builds, the instrumented build objects used a different
suffix (.i_o) to separate them from the profile-use build (which uses
the default .o suffix). These builds are now always in separate objdirs,
and don't need special suffix rules anymore.
As a bonus, this helps fix an issue with buildid.cpp continually
rebuilding because libxul_so.list always lists the inputs as *.o, which
don't exist if we're using a .i_o suffix. Make would always re-create
buildid.cpp and therefore libxul.so in the instrumented build even when
nothing has changed.
Differential Revision: https://phabricator.services.mozilla.com/D56115
--HG--
extra : moz-landing-system : lando
This was used for Windows MSVC PGO builds that re-used the objdir. We
don't use MSVC for PGO anymore, and we don't re-use the objdir.
Differential Revision: https://phabricator.services.mozilla.com/D56114
--HG--
extra : moz-landing-system : lando
MOZ_1TIER_PGO was a temporary hack to support 1-tier PGO builds while
they were being ported to 3-tier. Now that all builds are 3-tier, it can
be removed.
Differential Revision: https://phabricator.services.mozilla.com/D56112
--HG--
extra : moz-landing-system : lando
Add backend stuff to build sandboxed wasm libraries. (Don't actually update any moz.build files to consume this yet.)
Differential Revision: https://phabricator.services.mozilla.com/D54152
--HG--
extra : moz-landing-system : lando
To get an accurate backtrace if the run task crashes, we need the
symbols from the instrumented build.
Depends on D53716
Differential Revision: https://phabricator.services.mozilla.com/D53717
--HG--
extra : moz-landing-system : lando
This file provides the implementation of js/Utility.h, so it should be renamed
to match the header name.
Differential Revision: https://phabricator.services.mozilla.com/D51378
--HG--
rename : js/src/jsutil.cpp => js/src/util/Utility.cpp
extra : moz-landing-system : lando
For files with lots of dependencies (i.e. libxul), printing out the
entire list of changed files can be tedious. Instead, let's pick some
reasonable limit for the number of files we'll explicitly show, and
indicate that there are more files (but not print them out) for cases
that exceed that limit.
Differential Revision: https://phabricator.services.mozilla.com/D51913
--HG--
extra : moz-landing-system : lando
The current coreaudio-sys in gecko is a custom 0.2.2 version that used
to avoid the cross-compiling issue mentioned in bug 1569003. The issue
has been fixed in the coreaudio-sys 0.2.3, so we should follow the
upstream instead of using a custom version. As a result, the
coreaudio-sys would generate API bindings based on the MacOS SDK defined
in the build settings.
Differential Revision: https://phabricator.services.mozilla.com/D50531
--HG--
extra : moz-landing-system : lando
.cargo/config is necessary for all invocations of cargo, which, apart
from normal rust targets, actually also happens indirectly when we
invoke cbindgen.
Differential Revision: https://phabricator.services.mozilla.com/D50550
--HG--
extra : moz-landing-system : lando
"disjunction" and "unit" types aren't yet supported, because ICU doesn't
provide a C-API for this functionality. "short" and "narrow" styles aren't
supported for the same reason.
Differential Revision: https://phabricator.services.mozilla.com/D40437
--HG--
extra : moz-landing-system : lando
This does many things:
1) stops producing (and consuming) `FennecJNI*` JNI wrappers
2) removes the :app and :thirdparty Gradle projects
3) removes relevant pieces of the Gradle target configuration
4) updates lints
5) purges old configurations
After this commit, the `mobile/android` project/application builds
only GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D46536
--HG--
extra : moz-landing-system : lando
And add them to the UseCounter enum. Also add some sanity-check assertions that
the reporting code relies on.
This works much like the deprecated operation list.
Differential Revision: https://phabricator.services.mozilla.com/D44696
--HG--
extra : moz-landing-system : lando
And add them to the UseCounter enum. Also add some sanity-check assertions that
the reporting code relies on.
This works much like the deprecated operation list.
Differential Revision: https://phabricator.services.mozilla.com/D44696
--HG--
extra : moz-landing-system : lando
And add them to the UseCounter enum. Also add some sanity-check assertions that
the reporting code relies on.
This works much like the deprecated operation list.
Differential Revision: https://phabricator.services.mozilla.com/D44696
--HG--
extra : moz-landing-system : lando
If the run task generates bad profile data, the merge step in the
profile-use task will fail. However, retrying the profile-use task
doesn't fix the problem, and there isn't a straightforward way to retry
the run task in this situation. Instead we can add a clang toolchain to
all the run tasks, and perform the merge there.
This means the output from the run task will always be a successfully
merged file called 'merged.profdata', and we no longer need to perform
the merge as part of the profile-use build as a GENERATED_FILES step.
Depends on D45262
Differential Revision: https://phabricator.services.mozilla.com/D45263
--HG--
extra : moz-landing-system : lando
Bug 1578254 added a dependency on .cargo/config to export, which happens
to work in the python/mozbuild/mozbuild/test/backend/test_build.py test
cases because DEPTH=., and make finds the checked-in file .cargo/config
in topsrcdir because VPATH points there. After removing VPATH in bug
1496746, the test no longer finds the file in topsrcdir, and doesn't
have a rule to build it since that exists in the top-level moz.build
file.
Differential Revision: https://phabricator.services.mozilla.com/D45261
--HG--
extra : moz-landing-system : lando
Having a full VPATH for the srcdir sometimes causes make to grab the
wrong prerequisite for a rule, in particular if we have a file in the
srcdir and also generate a file of the same name in the objdir. We don't
really need VPATH anymore though, since most of the information comes
from mozbuild, where we can explicitly list the path to the srcdir or
objdir as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D42968
--HG--
extra : moz-landing-system : lando
One of the things bug 1567616 did was to change how .cargo/config is
preprocessed, from it happening during configure to it happening during
the build. And to make things happen properly, dependencies were added
on the rust targets to ensure the .cargo/config file is created before
they run.
Unfortunately, that changed the order in which Make would run all the
targets while recursing for the compile tier, when the file doesn't
exist first. So instead of starting the compile tier with rust targets,
it would start with most C++, then do rust... which we know to make
builds slower overall because of the need to wait for those rust builds
to finish which C++ has all been dealt with already, and lacking
parallelism during the rust build.
So we force .cargo/config to be generated during export (which it is not
already because OBJDIR_PP_FILES are currently dealt with during misc).
That makes Make still run the rust targets early during the compile
tier.
And while here, we extend the if block in recurse.mk that excludes all
the top-level recursion dependencies when running from subdirectories.
Differential Revision: https://phabricator.services.mozilla.com/D44992
--HG--
extra : moz-landing-system : lando
I'm not sure how things have worked without these headers getting
wrapped, but they need to be for declarations in them to work properly.
Differential Revision: https://phabricator.services.mozilla.com/D44690
--HG--
extra : moz-landing-system : lando
-Fd is the parameter accepted by clang. -PDB is the parameter accepted by lld-link. Additionally, to produce a pdb you apparently also need the -DEBUG flag
Differential Revision: https://phabricator.services.mozilla.com/D43525
--HG--
extra : moz-landing-system : lando
We'll require preprocessing that configure subst files don't allow in
the next change, so prepare for that.
Differential Revision: https://phabricator.services.mozilla.com/D43011
--HG--
extra : moz-landing-system : lando
We don't actually care that much about LTO'ing the rust parts of libxul
for gtests, and not LTO'ing it would save multiple minutes of build time
on automation.
Differential Revision: https://phabricator.services.mozilla.com/D42812
--HG--
extra : moz-landing-system : lando
André Bargull
Mozilla Releng Treescript
Bogdan Tara
Ricky Stewart
Kirk Steuber
Jamie Nicol
Nika Layzell
Jan de Mooij
David Major
Jan Beich
Mike Hommey
Sylvestre Ledru
Michal Novotny
Iain Ireland
Oana Pop Rus
William Lachance
Michael Woerister
Anthony Ramine
Narcis Beleuzu
Mike Shal
Daniel Varga
ffxbld
Greg V
Tooru Fujisawa
Marco Bonardo
Csoregi Natalia
Nick Alexander
Nathan Froyd
Cosmin Sabou
Brindusan Cristian
shindli
shravanrn@gmail.com
Marco Castelluccio
Dzmitry Malyshau
Coroiu Cristina
Noemi Erli
Ben Iofel
Razvan Maries
Tom Ritter
Andreea Pavel
Chris Manchester
Jesse Schwartzentruber
Landry Breuil
Chun-Min Chang
Christian Holler
Emilio Cobos Álvarez
Karl Tomlinson
Kai Engert
championshuttler