Setting this flag still attempts to build with 1-tier PGO, unless we
detect that 3-tier PGO is enabled. Since we should be using 3-tier PGO
everywhere, the flag should be redundant in our automation mozconfigs.
It can still be used locally in a mozconfig to do a 1-tier PGO build.
Depends on D46069
Differential Revision: https://phabricator.services.mozilla.com/D46070
--HG--
extra : moz-landing-system : lando
This file is no longer required, since taskcluster handles scheduling
PGO tasks.
Differential Revision: https://phabricator.services.mozilla.com/D46069
--HG--
extra : moz-landing-system : lando
In the MinGW build, calls to malloc inside mozglue were not being
redirected as defined in the .def file. We create aliases for the
redirected functions to correctly redirect them inside mozglue.
An alternate solution for this exists. Rather than creating the
importlib during the linking step for mozglue, we could have used
dlltool to create it, and then provided it during linking. This
would allow mozglue to know that it should redirect calls to malloc
to je_malloc as specified in the .def file.
Differential Revision: https://phabricator.services.mozilla.com/D38407
--HG--
extra : moz-landing-system : lando
We don't need to disable it. The problem with this commit is that
we want to keep the --disable-maintenance-service flag working, so
we might want a separate build for that (and other unusual --disable
flags) - but such a build can be clearly labeled so people understand
why things broke.
Differential Revision: https://phabricator.services.mozilla.com/D43145
--HG--
extra : moz-landing-system : lando
The mozconfig in the task definition is overriden in hazard-browser.sh,
so it has effectively no effect, and hazard-browser.sh has been using
js/src/devtools/rootAnalysis/mozconfig.haz since bug 1321014.
Differential Revision: https://phabricator.services.mozilla.com/D41879
--HG--
extra : moz-landing-system : lando
The remaining uses all need adjustements to in-tree mozconfigs, so they
all need to be done at once.
However, to make things slightly more intelligible, we do this in two
steps. This is step 1: we modify the use_toolchain transform to take care of
the transformation, while keeping the task definitions intact, so that
we only deal with mozconfig and build script adjustements here.
Differential Revision: https://phabricator.services.mozilla.com/D41890
Bug 1553065 made this redundant by putting the profile-use mozconfig
settings in build/unix/mozconfig.unix. We no longer need them in each
leaf mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D36543
--HG--
extra : moz-landing-system : lando
We don't run any tests on these builds, since they are just used to
generate the profile data for the final build. We can save some time by
skipping all test related code.
Differential Revision: https://phabricator.services.mozilla.com/D36511
--HG--
extra : moz-landing-system : lando
The 3-tier PGO builds used a separate mozconfig called 'profile-use' for
the final tier. This created a problem when it rode to beta, since the
same mozconfig was used for all trees, which meant we ended up with
nightly branding on beta builds.
With the PGO-enabling logic in common mozconfigs, we can enable it by
setting the MOZ_PGO_PROFILE_USE environment variable from the task
definition. All of the final-tier PGO builds now use the nightly, beta,
etc mozconfigs like before, so branding should be intact.
Differential Revision: https://phabricator.services.mozilla.com/D33172
--HG--
extra : moz-landing-system : lando
MOZ_INCLUDE_SOURCE_INFO is needed for us to write out the MOZ_SOURCE_URL
in sourcestamp.txt, and MOZ_INCLUDE_SOURCE_INFO is set in configure only
for MOZILLA_OFFICIAL=1 builds.
Differential Revision: https://phabricator.services.mozilla.com/D32519
--HG--
extra : moz-landing-system : lando
e10s profiling or IR-based PGO instrumentation will both produce
multiple `.profraw` files that need to be handled in some way. Since
clang's `-fprofile-generate` option takes a directory, it seems fitting
to make `--with-pgo-profile-path` mirror that by taking a directory, and
letting `merge_profdata.py` deal with whatever files it might find in
said directory.
Differential Revision: https://phabricator.services.mozilla.com/D32389
--HG--
extra : moz-landing-system : lando
They were disabled in bug 1370129 because there were no use cases for them, but
there are use-cases for at least the linux64 ones :)
Let me know if you want me to enable them everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D30797
--HG--
extra : moz-landing-system : lando
Tor compiles with these, using the mingw build, so it makes sense to
replicate their configuration.
Differential Revision: https://phabricator.services.mozilla.com/D28939
--HG--
extra : moz-landing-system : lando
Changes --enable-verify-mar to be the default. Builds that want to disable mar verification will need to specify --disabled-verify-mar.
Removes --enable-verify-mar from Firefox's mozconfigs since it is no longer needed.
Re-enables app update browser chrome tests on ASAN that were disabled due to the ASAN mozconfigs not specifying --enable-verify-mar.
This also makes the same app update browser chrome tests on code coverage builds due to the code coverage mozconfigs not specifying --enable-verify-mar.
Differential Revision: https://phabricator.services.mozilla.com/D28288
--HG--
extra : moz-landing-system : lando
After bug 1530908 changed LTO to be environment driven, the macosx64
nightly mozconfig enables LTO by setting MOZ_LTO=1. The add-on-devel
mozconfig tried to disable LTO by using --disable-lto, but the
environment variable takes precedence, leaving LTO enabled for these
builds. This pushed the build time up to be close to the max runtime for
the task, causing frequent intermittent failures.
We should 'unset MOZ_LTO' everywhere that --disable-lto was used, and
'export MOZ_LTO=1' everywhere --enable-lto was used.
Differential Revision: https://phabricator.services.mozilla.com/D26608
--HG--
extra : moz-landing-system : lando