OSX (cross) repackages are currently using a tooltool manifest to get
libdmg and hfsplus. Change those jobs to use the toolchain artifacts
instead.
At the same time, modify the repackage mozharness script's _run_tooltool
so that it doesn't fail with MOZ_TOOLCHAINS being set but without a
tooltool_manifest_src, matching the similar function in buildbase.py.
--HG--
extra : rebase_source : d128d4709c5d1d28d1a6b9c585fde82e99f725c7
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
It turns out that in all cases it was the last tooltool manifest entry,
so we can remove the tooltool manifests entirely, and remove all
references to them.
--HG--
extra : rebase_source : d8447b5422e63e88444008fddb76d658829694de
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
It turns out that in all cases it was the last tooltool manifest entry,
so we can remove the tooltool manifests entirely, and remove all
references to them.
--HG--
extra : rebase_source : 0aa9ef8151c2fccf62507dfecc0bc57b157772e1
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
The "contract" for toolchains is that extracting foo.tar.xz creates a
directory named foo/. That is however not true for mingw32.tar.xz, which
extracts into gcc/, possibly overwriting files from the gcc.tar.xz
archive (which is also used for mingw builds, for the host part).
This is also not true for nsis.tar.xz, but it reportedly has problems
when it's not in the same directory as mingw32.
But mingw32 doesn't actually need to be mixed with gcc, so it's better
to separate them as they are supposed to be.
--HG--
extra : rebase_source : 30d90af64459bbb31bc076e48f3c661fa9cd4a79
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
exe_7z_archive.py runs during the MinGW build L10N check step, and
hardcodes 7z as the 7zip executable. This works on Windows, but not
Linux. We need to pass it the correct executable for 7zip, which is
located during configure.
However, repacks (repackage-winXX-nightly) don't do configure, and
don't have the tools to do configure. So we leave the default
command in the python script if one is not supplied.
MozReview-Commit-ID: B7GEKRYEJTD
--HG--
extra : rebase_source : 10ec7e688d53341625217306e88f2e647195ce8d
None of these are defined in any "nightly" mozconfigs.
Some of these lines may occur and be set by mozconfigs. But the
entire premise of compare-mozconfigs is flawed because it only compares
file content: not the end result of mozconfig evaluation. (mozconfigs
are shell scripts and a lot of logic occurs in other sourced shell
scripts.)
MozReview-Commit-ID: 2Nwo3ePJreb
--HG--
extra : rebase_source : 4fef846c6e501cef29ca9bca573f376e9ac2f97c
This variable isn't consumed anywhere. I have no clue where it
was consumed. It appears to be the product of an old era.
MozReview-Commit-ID: 6iRdLW89ZjW
--HG--
extra : rebase_source : d338287d78462a78cf70671b00d7cf1fd9520785
extra : source : aa0428bd81463d7e12454238681f27085678c92a
There are no other references to PROFILE_GEN_SCRIPT outside
of the mozconfig whitelist file. The deleted entries from the
whitelist file were meaningless.
MozReview-Commit-ID: IhOV8Hlfmhl
--HG--
extra : rebase_source : e118008a8a87c83e6e025eca9e7ce51ce8fce0a3
extra : source : 5280a8429e4174e1cb1e0dd4c5e34e9fe539b171
We no longer define MOZ_MAKE_FLAGS in the in-repo mozconfigs. Nor do we
pass MOZ_MAKE_FLAGS from any automation configs as far as I can tell.
MozReview-Commit-ID: LYU1dI44uhX
--HG--
extra : rebase_source : 08a9e7801ae619ba1cd36f6c262c29a4735035d0
extra : intermediate-source : 8430d8501abcd30d15e0ef73d9bfa64d6ede8697
extra : source : 3f151657ee8d7a5a87629826f654ee5c807b5346
--enable-elf-hack is the default on all platforms where it's supported,
and is completely ignored on platforms where it's not supported.
While moving the flag to moz.configure, we're going to make it only
work on platforms where elfhack is supported, so we at least need to
remove it from mozconfigs for those platforms where it's not supported.
But generally speaking, we want less things in mozconfigs, so just
remove it from there, since it's the default anyways.
With that fixed, Re-enable MOZ_AUTOMATION_L10N_CHECK for MinGW
MozReview-Commit-ID: BDTtY1J7sBj
--HG--
extra : rebase_source : 162267bf08a6e477af3b8b119a9ef9df65ba8267
This line was added to the nightly macosx64 mozconfig in 9312a1903bf4
(bug 1391643). But we didn't catch it because compare-mozconfigs
only analyzes the current platform and we cross compile for MacOS
from Linux.
MozReview-Commit-ID: 35Q2c0mybPi
--HG--
extra : rebase_source : 25707037ca07ec22de283abcfe96c4faea71d55e
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
The new VS package is now based on update 15.4.2, although that release didn't affect any files in our package. I'm picking up the update mostly just to make filename unique.
This also enables the crash reporter on the MinGW build, as this is the
only thing blocking that from working.
MozReview-Commit-ID: Hygd7UUQvwl
--HG--
extra : rebase_source : a4a12b8edaa5b1fba869d6f7c21fc8444be2d9d7
Mike Hommey
Coroiu Cristina
Andreea Pavel
Steve Fink
Ian Moody
Ted Mielczarek
Tom Ritter
David Major
Sylvestre Ledru
Dorel Luca
Sebastian Hengst
Cosmin Sabou
Jesse Schwartzentruber
Bill McCloskey
Gregory Szorc
Marco Castelluccio
Ryan VanderMeulen