Using @checking doesn't go well with the virtualenv creation, so print
the version information after the fact. And do so uniformely for python
2 and python 3.
Differential Revision: https://phabricator.services.mozilla.com/D69529
--HG--
extra : moz-landing-system : lando
This is yet another cargo-cult from virtualenv_python2, which is not
necessary because by the time we reach virtualenv_python3, the mozconfig
configure *has* been injected already.
Differential Revision: https://phabricator.services.mozilla.com/D69528
--HG--
extra : moz-landing-system : lando
It was cargo-culted from virtualenv_python2, but is not necessary
because virtualenv_python3 is not going to re-execute python, which is
what the dependency is there to avoid.
Differential Revision: https://phabricator.services.mozilla.com/D69527
--HG--
extra : moz-landing-system : lando
This was cargo-culted from virtualenv_python2, but this is not
necessary: currently, the only way configure code will execute with
python 3 is if something uses the configure sandbox from python 3, not
configure. Only configure itself is meant to re-execute itself with
python, so we don't want python 3 to re-execute.
We'll be swapping virtualenv_python2 and virtualenv_python3 later, when
switching to python 3.
Differential Revision: https://phabricator.services.mozilla.com/D69526
--HG--
extra : moz-landing-system : lando
* We change the SDK version to use build tools 29.0.3;
* We change `build_tools_version` from a list to a string;
* We convert `android_build_tools` to work correctly with the above change;
* We set the build tools version in configure, as gradle needs to access it
in a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D69631
--HG--
extra : moz-landing-system : lando
Switched handling of AppUpdate:URL from it being required to it being optional, much as Crash Reporter:serverurl is handled.
Differential Revision: https://phabricator.services.mozilla.com/D68606
--HG--
extra : moz-landing-system : lando
We only enabled hardening with an explicit --enable-hardening because we
needed a patch. That patch was applied to upstream clang 8.0.1, so we
can now enable automatically whenever using the right version.
The explicit --enable-hardening was also not applied to win64-aarch64
debug builds, and this indirectly enables it there too, matching other
debug builds. This also avoids breaking debug builds when enabling
winchecksec on cross builds.
Differential Revision: https://phabricator.services.mozilla.com/D68161
--HG--
extra : moz-landing-system : lando
This is required for llvm-mt, which building winchecksec will require.
We do a dummy change to build-clang.sh so as to change the toolchain
index hash.
Differential Revision: https://phabricator.services.mozilla.com/D68153
--HG--
extra : moz-landing-system : lando
This is being added to facilitate moving generation of the update URL to Rust (Bug 1567286). Once that has been completed, we should be able to remove the update URL from its current location in firefox.js so that it is not being duplicated in application.ini.
Differential Revision: https://phabricator.services.mozilla.com/D43300
--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
After cargo 7caa161, which was included in rust 1.43 nightly 2020-02-23 as part of rust 11530de, if you don't have rustc installed in the normal place (which our CI builders don't) then you need to specify RUSTC explicitly during cargo metadata or else the call will fail. In our build system, the RUSTC wasn't being passed through in RunCbindgen.py.
Differential Revision: https://phabricator.services.mozilla.com/D68086
--HG--
extra : moz-landing-system : lando
Specifically, this renames
* nsTArray_CopyChooser to nsTArray_RelocationStrategy
* the Copy template argument of nsTArray_base to RelocationStrategy
* nsTArray_CopyWithConstructors to nsTArray_RelocateUsingMoveConstructor
* nsTArray_CopyWithMemutils to nsTArray_RelocateUsingMemutils
* DECLARE_USE_COPY_CONSTRUCTORS to MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR
Differential Revision: https://phabricator.services.mozilla.com/D66243
--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
Remove the remainder of automation.py.in and the build support for generating
automation.py.
Some of this functionality was in use, especially for android tests.
Some code was moved or re-implemented in remoteautomation.py or in the affected
harness(es). Some features were removed: There are some minor changes in behavior.
For instance, instead of using a different server startup timeout for debug builds,
one value is used for all builds (due to performance improvements over time,
the longer timeout is no longer needed).
Differential Revision: https://phabricator.services.mozilla.com/D66839
--HG--
extra : moz-landing-system : lando
Several developers have reported hangs on native Mac builds. I think we should disable the flag on Mac hosts. Even if we could fix the current hangs, without coverage in CI for this build configuration, we're asking for more trouble down the road.
Differential Revision: https://phabricator.services.mozilla.com/D67007
--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
It turns out clang-cl adds an explicit /DEFAULTLIB:/full/path/to/runtime
to all the .obj it creates, which makes the linker add it on its own.
Differential Revision: https://phabricator.services.mozilla.com/D66368
--HG--
extra : moz-landing-system : lando
This is both for future proofing (fetches could move any time although
they likely won't), and to fix the path on the future Windows PGO
cross builds, where the fetches path is not under $WORKSPACE.
Differential Revision: https://phabricator.services.mozilla.com/D66358
--HG--
extra : moz-landing-system : lando
LLVM's new pass manager has been in the works for several years and has better optimization (sometimes much better) than the legacy pass manager. I think it's in good enough shape for us to try at this point.
While we only really need the new pass manager for shippable builds, as a general principle I'd like to use it as much as possible, to help catch bugs for upstream. Therefore this patch enables the new pass manager by default for all clang builds, with the only exceptions being compilers older than version 9, and xcode clang where we can't trust the version number. There isn't a specific problem with older versions; I just don't want to sign up for the support cost of debugging people's local builds that may be fixed already.
I don't expect it to be necessary, but just in case, an opt-out is available via `ac_add_options --disable-new-pass-manager`.
Differential Revision: https://phabricator.services.mozilla.com/D66109
--HG--
extra : rebase_source : 91df800146700e4958b8e645ebbd3cf7b11a2f1e
extra : source : 2f5aba2e2c099a1df26e3444ccec2be0b4ff4613
LLVM's new pass manager has been in the works for several years and has better optimization (sometimes much better) than the legacy pass manager. I think it's in good enough shape for us to try at this point.
While we only really need the new pass manager for shippable builds, as a general principle I'd like to use it as much as possible, to help catch bugs for upstream. Therefore this patch enables the new pass manager by default for all clang builds, with the only exceptions being compilers older than version 9, and xcode clang where we can't trust the version number. There isn't a specific problem with older versions; I just don't want to sign up for the support cost of debugging people's local builds that may be fixed already.
I don't expect it to be necessary, but just in case, an opt-out is available via `ac_add_options --disable-new-pass-manager`.
Differential Revision: https://phabricator.services.mozilla.com/D66109
--HG--
extra : moz-landing-system : lando
Remove unused code from automation.py.in, move some android-specific code from
automation.py.in to remoteautomation.py, and eliminate some other easily-replaced
code. In the long term we want to eliminate automation.py.in completely; I may
attempt that once these changes have landed.
Differential Revision: https://phabricator.services.mozilla.com/D66306
--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
Otherwise, the error is never visible to the build system, taskcluster,
treeherder, and, ultimately, this defeats the purpose of the check.
Differential Revision: https://phabricator.services.mozilla.com/D67414
--HG--
extra : moz-landing-system : lando
The tweaks are essentially the same as for win64 builds, with the only
differences being the path for the VC binary directory and the addition
of a WINEPATH for the additional path to load the DLLs necessary to run
asmarm64.exe.
Differential Revision: https://phabricator.services.mozilla.com/D65481
--HG--
extra : moz-landing-system : lando
The tweaks are essentially the same as for win64 builds, with the only
difference being the path for the VC binary directory.
Differential Revision: https://phabricator.services.mozilla.com/D65480
--HG--
extra : moz-landing-system : lando
The key here is to test the type of the variable declaration for being a
smartptr type, instead of testing the type of the variable _use_.
Differential Revision: https://phabricator.services.mozilla.com/D65581
--HG--
extra : moz-landing-system : lando
With this and all the previous changes, the necessary mozconfig for
local cross-builds only contains DIA_SDK_PATH, WINDOWSSDKDIR and
--target.
Differential Revision: https://phabricator.services.mozilla.com/D65295
--HG--
extra : moz-landing-system : lando
This was cargo culted from the autoconf equivalent, and while it makes a
command that does "$(PROG) foo" work because it becomes ": foo", that
may or may not actually be a desirable outcome.
OTOH, we do have some places where there are some "ifdef PROG" that are
just plain wrong when PROG is always actually set.
One place I do know that does check if the value is not ":" is for
OBJCOPY, which is still set from autoconf.
All in all, looking at all the check_prog(allow_missing=True) we have in
python configure, it doesn't seem anything is checking for ":", and that
doesn't seem like the right status quo.
Differential Revision: https://phabricator.services.mozilla.com/D65276
--HG--
extra : moz-landing-system : lando
On Linux and Mac, this makes `dmd.py` *much* faster when it is first run on a
DMD data file.
On Windows, this makes DMD actually usable locally. Previously the stacks
weren't fixed and so were rubbish.
Differential Revision: https://phabricator.services.mozilla.com/D57271
--HG--
extra : moz-landing-system : lando
CLOSED TREE
Backed out changeset 01548614184b (bug 1602773)
Backed out changeset 430c8e6b0c5a (bug 1602773)
Backed out changeset 1b4e2b044fcd (bug 1602773)
- 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
One part is fixing old-configure.in to use `pwd` when `pwd -W` doesn't work
(it errors on Linux), and another part is supporting two additional
system calls in liblowercase:
- chdir used in the same commands as the `pwd -W` fix
- symlink, used by the install manifest processor to create symbolic
links of those DLLs in $MOZ_OBJDIR/dist/bin.
Differential Revision: https://phabricator.services.mozilla.com/D64707
--HG--
extra : moz-landing-system : lando
This is to fix build bustage until Thunderbird engineers are able to migrate
these threads to use background tasks.
Differential Revision: https://phabricator.services.mozilla.com/D64795
--HG--
extra : moz-landing-system : lando
Mike Hommey
Aaron Klotz
Tarek Ziadé
Sebastian Hengst
Kirk Steuber
Stephen A Pohl
Bogdan Tara
James Willcox
Ian Neal
Christian Holler
Ricky Stewart
David Major
Simon Giesecke
Oana Pop Rus
Noemi Erli
Arthur Iakab
Andi-Bogdan Postelnicu
Sylvestre Ledru
Geoff Brown
Andreea Pavel
Marco Bonardo
Mike Shal
Nathan Froyd
Narcis Beleuzu
Alessio Placitelli
Tom Schuster
Emilio Cobos Álvarez
Daniel Varga
Ehsan Akhgari
Emma Malysz
Boris Zbarsky
june wilde
Nicholas Nethercote
Tyson Smith
Kershaw Chang
Mihai Alexandru Michis
Csoregi Natalia
Sebastian Streich
Rob Lemley
Tooru Fujisawa