Otherwise, PGO builds would fail to find asan at stage2 because the instrumented build uses `LLVM_BUILD_RUNTIME=No`.
Differential Revision: https://phabricator.services.mozilla.com/D69082
--HG--
extra : moz-landing-system : lando
This will partially atone for making builds longer with PGO.
Depends on D69618
Differential Revision: https://phabricator.services.mozilla.com/D69620
--HG--
extra : moz-landing-system : lando
This also does a few remaining python 2 incompatible changes to
.configure files.
Differential Revision: https://phabricator.services.mozilla.com/D69538
--HG--
extra : moz-landing-system : lando
This adds the ability to do four-stage PGO builds. This was surprisingly straightforward thanks to PGO being a well-supported scenario in LLVM's cmake.
For reference, the stages are:
stage1: Initial build with gcc
stage2: Instrumented build using stage1
stage3: Train by using the instrumented stage2 to build the clang tree
stage4: Optimize using the stage3 compiler and the profdata created with it
Differential Revision: https://phabricator.services.mozilla.com/D69080
--HG--
extra : moz-landing-system : lando
Separating out the mechanical/"boring" changes to make the next patch more clear. This patch adds the ability to build a fourth stage that for now doesn't do anything special.
I changed to using >= to make it more obvious that e.g. "here is what's going to happen for stage 2" -- the off-by-one was too hard on my brain.
Differential Revision: https://phabricator.services.mozilla.com/D69079
--HG--
extra : moz-landing-system : lando
Otherwise, PGO builds would fail to find asan at stage2 because the instrumented build uses `LLVM_BUILD_RUNTIME=No`.
Differential Revision: https://phabricator.services.mozilla.com/D69082
--HG--
extra : moz-landing-system : lando
This will partially atone for making builds longer with PGO.
Depends on D69618
Differential Revision: https://phabricator.services.mozilla.com/D69620
--HG--
extra : moz-landing-system : lando
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
