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
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
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
We need to install a new enough binutils for both of these jobs and
ensure that it's properly found on the linux job.
Differential Revision: https://phabricator.services.mozilla.com/D23678
--HG--
extra : moz-landing-system : lando
These builds no longer use gcc, so they no longer need gcc files on PATH
or LD_LIBRARY_PATH.
Differential Revision: https://phabricator.services.mozilla.com/D22712
--HG--
extra : moz-landing-system : lando
Artifact mozconfigs are not necessarily up-to-date wrt changes to the
nightly mozconfigs, and all in all, shouldn't be much different from
them.
It's just better to use the nightly mozconfigs (or beta on beta, etc.)
and make the mozconfigs themselves handle the few things that need to be
different when the USE_ARTIFACT environment is set (which is now
consistently set by taskcluster)
This does have the side effect of turning builds that actually don't
support artifact builds red when using --artifact on try, instead of
having them silently not be artifact builds as currently happens.
Depends on D21314
Differential Revision: https://phabricator.services.mozilla.com/D21315
--HG--
extra : moz-landing-system : lando
And remove the manual --enable-dmd in in-tree mozconfigs, as well as
--enable-profiling, which is implied by --enable-dmd.
This disables DMD on add-on-devel builds, which don't look like they
were actually meant to have DMD enabled in the first place (they only do
because they use the nightly mozconfig on all branches, and as a matter
of fact, the nightly mozconfig didn't enable DMD before bug 1409739)
This enables DMD on mingw builds with the same conditions applied as
other platforms, meaning that it's not enabled on opt builds on release
branches.
And this enables DMD on plain builds, which, from this perspective,
reflect local developer builds, and this is the expected effect.
Depends on D21161
Differential Revision: https://phabricator.services.mozilla.com/D21162
--HG--
extra : moz-landing-system : lando
Cosmin Sabou
Marco Castelluccio
Dorel Luca
Mike Shal
Julien Cristau
David Major
Sylvestre Ledru
Mike Hommey
Eric Rahm
Nathan Froyd
Emilio Cobos Álvarez
Robert Strong
Christian Holler
Noemi Erli
Ciure Andrei
Andreea Pavel
Brindusan Cristian