Local PGO builds now use 3-tier machinery under the hood. Instead of a
single object directory that gets cleaned in between the instrumented
and profile-use builds, now the instrumented build uses a separate
'${objdir}/instrumented' directory. This makes it easier to handle
within mach since we can drive the two builds with environment variables
and keep all build artifacts separate, without needing to do manual
cleanup in between.
Differential Revision: https://phabricator.services.mozilla.com/D50098
--HG--
extra : moz-landing-system : lando
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
Gabriele Svelto
Gregory Szorc