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
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
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
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
Two mozconfg additions are necessary for these jobs on linux:
1.) Turning off the clang plugin, which will not get built during these builds
and will cause failures when C/C++ needed by the rust build tries to find it.
2.) Adding --output-sync=line to our make invocation: at some point the
"export" phase started relying on this, and it's missing because the
non-default build targets invoked by the rusttests builds don't go through
client.mk.
Differential Revision: https://phabricator.services.mozilla.com/D11242
--HG--
extra : moz-landing-system : lando
We need to sign parts of the contents of the archives, so the mar's that we
ship get built as part of the repackage task. Thus, there is no reason to also
create and upload as part of the build, just to throw them away.
Differential Revision: https://phabricator.services.mozilla.com/D6213
--HG--
extra : moz-landing-system : lando
Some mozconfigs actually rely on testing whether the variable is set or
not, which may or may not depending on the mozharness configuration,
and doesn't necessarily match what the mozconfigs do.
So in all mozconfigs that enable PGO, make them use an environment
rathen than ac_add_options.
Differential Revision: https://phabricator.services.mozilla.com/D5843
--HG--
extra : moz-landing-system : lando
As of bug 1430036 it was only set when building on CentOS, and as of bug
1432398, we don't have CentOS-based docker images anymore.
--HG--
extra : rebase_source : 5ade9bee773bca3283cfdb9d69209033fe82253f
moz.configure automatically enables profiling if the milestone is
Nightly (see js/moz.configure:226). So, --enable-profiling in the
nightly mozconfigs is redundant and can be removed.
The whitelist has also been updated to reflect the removal of this
line.
MozReview-Commit-ID: 7nUJVcFOp6c
--HG--
extra : rebase_source : 86db8c2bf646c83701ade8c4a10d667d1c2da6f1
The reason it was set from mozconfigs is that profiling require it. But
since it was added, bug 751355 made it implied by --enable-profiling,
and bug 1144842 further made sure that profiling and STRIP_FLAGS were
tied together.
--HG--
extra : rebase_source : c2a6b03bf007e661db48e40cca98e81aaa04c878
It now only does something trivial, which also happens to be a no-op
because it's the default. It does have a commented entry for possible
gtk+2 builds, but we're soon going to remove that possibility anyways in
bug 1278282.
--HG--
extra : rebase_source : 9ac927bb7bd8c057264c8f6f9ca5cbf79a839c4e
Now that build environment docker images have gtk+3 installed in
/usr/local, adjust mozconfigs to point pkg-config there, and remove
all the glue that was required to build using the tooltool package.
Also remove the --x-libraries=/usr/lib on 32-bits builds, which only
confuses the linker.
--HG--
extra : rebase_source : c7de7b3959a3c6b77ea202d9609c891b5b7ec442
It now only does something trivial, which also happens to be a no-op
because it's the default. It does have a commented entry for possible
gtk+2 builds, but we're soon going to remove that possibility anyways in
bug 1278282.
--HG--
extra : rebase_source : 0de751e523ee002bbe6638d223eb384364edd22b
Now that build environment docker images have gtk+3 installed in
/usr/local, adjust mozconfigs to point pkg-config there, and remove
all the glue that was required to build using the tooltool package.
Also remove the --x-libraries=/usr/lib on 32-bits builds, which only
confuses the linker.
--HG--
extra : rebase_source : 22b1273ae4b78807b355d33ed5895bdfe83a141d
At the same time, we make it actually do something on spidermonkey
builds. We also add an environment variable alternative, that we use
in mozconfig.stdcxx, allowing for mozconfig.no-compile to override it
and avoid configure failures on e.g. artifact builds.
--HG--
extra : rebase_source : b68d362025e0c99f9184a03391c652ec2c9357ad
With all of our builds in Taskcluster now, we should never be uploading
symbols from build tasks. Unfortunately Windows builds were still doing so.
This patch removes MOZ_AUTOMATION_UPLOAD_SYMBOLS from all the in-tree
mozconfigs and a few other places so that it should always default off
(per moz-automation.mk). The rest of the uploadsymbols bits will be
removed once Thunderbird fixes their automation.
This patch was mostly autogenerated by running:
rg --files-with-matches UPLOAD_SYMBOLS browser/config/mozconfigs/ mobile/android/config/mozconfigs/ | xargs sed -ri '/.*UPLOAD_SYMBOLS.*/d'
sed -ri '/.*UPLOAD_SYMBOLS.*/d' build/unix/mozconfig.linux build/mozconfig.win-common build/macosx/local-mozconfig.common build/mozconfig.automation
Then mobile/android/config/mozconfigs/common and
taskcluster/scripts/builder/build-linux.sh were hand-edited.
MozReview-Commit-ID: Cy8kSEodSg4
--HG--
extra : rebase_source : 01caf1651b4eb428313e1f371aa585f8f34c4151
The mechanism by which PGO builds are kicked off is kinda wonky.
The MOZ_PGO environment variable is recognized by configure and setting
it will result in MOZ_PGO being defined in substs. In addition, the
build backend (previously client.mk, now Makefile.in) also recognizes
MOZ_PGO (from mozconfig or environment) and takes appropriate action.
In-tree mozconfigs set MOZ_PGO via mk_add_options. mk_add_options
is intended as a mechanism to inject state into client.mk and the
make-based build system.
In addition, there is code in mozharness (unchanged by this commit)
that sets MOZ_PGO if appropriate.
A PGO build configuration is different from a non-PGO build
configuration. Therefore a make-centric environment variable to
control PGO is not ideal. Instead, this should be defined as a
configure-time flag and the build invocation should key off that.
This commit normalizes in-tree mozconfigs to set MOZ_PGO via
ac_add_options and updates the PGO documentation to recommend
this method.
MozReview-Commit-ID: k6AZyJuXjs
--HG--
extra : rebase_source : b1a6348611eba08dd67ec938cca5586fbe8e6910
extra : source : 25c7ebc7c44dd253f421b6de3d0337635d0c99d0
Mike Shal
Mike Hommey
Robert Strong
Sylvestre Ledru
Brindusan Cristian
Ciure Andrei
Chris Manchester
Chris AtLee
Cosmin Sabou
Coroiu Cristina
Gurzau Raul
Tom Prince
Dan Mosedale
Jesse Schwartzentruber
Gregory Szorc
Ted Mielczarek
Sebastian Hengst