The output from running the browser during PGO builds can have innocuous
error messages in them, but show up in treeherder as potential messages
to include when filing bugs. We can just save the output from these runs
as files and upload them as artifacts instead, so they don't show up in
the build log but are available for inspection if necessary.
MozReview-Commit-ID: 3VdVCKVkZNI
Differential Revision: https://phabricator.services.mozilla.com/D15154
--HG--
extra : moz-landing-system : lando
In bug 1259382, some workarounds were added to make the build system
alter PATH and not use absolute paths for toolchain programs, because
autoconf and the build system doesn't deal with spaces in those very
well. But later in bug 1290040, we made find_program return Windows
short paths (without spaces), which alleviates the need for those
workarounds.
We still, however, and unfortunately, need to alter PATH to account for
the fact that MSVC DLLs are not necessarily alongside the compiler
executables...
Depends on D15181
Differential Revision: https://phabricator.services.mozilla.com/D15182
--HG--
extra : moz-landing-system : lando
Like for other windows platforms. This currently doesn't make a
difference, but will with next change.
Differential Revision: https://phabricator.services.mozilla.com/D15181
--HG--
extra : moz-landing-system : lando
We remove --disable-libjpeg-turbo because that's only useful when Yasm
is too old, and the required version is now almost 8 years old, so we
can reasonably require people to upgrade rather than workaround with a
--disable option.
The valid_yasm_version function can seem overkill, but that's because
future moves of other things to python configure will pile up.
Differential Revision: https://phabricator.services.mozilla.com/D15184
--HG--
extra : moz-landing-system : lando
Now that we're not even building host static libraries, we don't need
variables for the tools used to build them.
Ironically, we weren't even running HOST_RANLIB.
Depends on D15172
Differential Revision: https://phabricator.services.mozilla.com/D15173
--HG--
extra : moz-landing-system : lando
So far, the main subject of cross-compiles was to cross compile from one
OS to another (e.g. {linux,osx} -> android), but there are a few useful
cases where the OS doesn't change, and, with --host being guessed, we
can just have developers pass --target=$cpu instead of a complete
target triplet. This can be useful to do x86 Linux builds on x86-64
Linux hosts, or aarch64 Windows builds on x86-64 Windows hosts.
Differential Revision: https://phabricator.services.mozilla.com/D15063
--HG--
extra : moz-landing-system : lando
Remove the version check for WINDRES, because, as per bug 454112, it
didn't actually work, and, making it work actually causes problems
because llvm's windres, used with mingw clang, has version 0.1.
Differential Revision: https://phabricator.services.mozilla.com/D15070
--HG--
extra : moz-landing-system : lando
vswhere only searches in Community, Professional and Enterprise, but one can
also install BuildTools only, which has a different product name.
Differential Revision: https://phabricator.services.mozilla.com/D15056
--HG--
extra : moz-landing-system : lando
It will be useful to run tests like try_compile, with different flags and different
kinds of sources.
Depends on D14949
Differential Revision: https://phabricator.services.mozilla.com/D14950
--HG--
extra : moz-landing-system : lando
Although this task technically doesn't build a toolchain, the set of
steps it needs to do is very similar to what a toolchain build does, so
we're shoehorning this task into the toolchain kind. The task basically
runs `cargo vendor` on the gfx/wr/Cargo.lock file (if/when it changes)
and exports a tarball of the resulting vendored crates. This allows
downstream tasks that build stuff in gfx/wr to not have to re-fetch
these crates from crates.io on every test run.
Differential Revision: https://phabricator.services.mozilla.com/D14406
--HG--
extra : moz-landing-system : lando
The SQLite in Debian 7 (3.7.13) lacks support for common table
expressions (the WITH keyword), which was introduced in SQLite
3.8.3. The Mercurial SQLite storage backend currently relies on
CTEs. Even if a future Mercurial doesn't require CTE, it is likely
that it will still use CTE if available for performance reasons.
So, it is in our best interest to give Mercurial access to a
modern SQLite. Plus, using a modern SQLite and avoiding potential
bugs in old versions seems prudent.
This commit introduces a SQLite package backport for Debian 7
so we can use the new SQLite feature. We had to minimally patch
the build to work with an older version of TCL that isn't using
multiarch.
I observed libsqlite3 being installed as part of building various
other packages (such as Python). I initially added the package as
a dependency so packages would be built against a more modern
SQLite. But glandium doesn't believe it matters, since nothing
should be doing build-time feature detection. Python is the most
important downstream package (since Mercurial uses its SQLite).
I audited the CPython build system and did not see any build-time
SQLite feature detection or version sniffing. So I think we'll be
fine building against an older SQLite.
Differential Revision: https://phabricator.services.mozilla.com/D14194
--HG--
extra : moz-landing-system : lando
We don't care anymore: the Gradle build fetches an appropriate version
of the build-tools package, and the one build-tool we actually use --
zipalign -- isn't version sensitive.
Differential Revision: https://phabricator.services.mozilla.com/D14290
--HG--
extra : moz-landing-system : lando
There's no need -- it will be fetched by Gradle when needed. The only
wrinkle is that the user might be asked to confirm license agreements,
which could be a hassle (and could cause problems in CI, but there we
install relevant platforms in advance).
Differential Revision: https://phabricator.services.mozilla.com/D14288
--HG--
extra : moz-landing-system : lando
The build system no longer invokes these directly: they're all fetched
and invoked by Gradle and its plugins.
Differential Revision: https://phabricator.services.mozilla.com/D14287
--HG--
extra : moz-landing-system : lando
