In bug 1494022 there are problems using an SDK that is too new, which
can cause developers to spend many hours debugging an issue that we
could've checked up front.
This patch gets the version from the SDKSettings.plist file at the root
of the SDK directory, and checks it against min and max supported
versions.
The current min version is 10.11, since that is what we build with in
automation. The current max version is 10.13, since 10.14+ currently has
an issue with a black screen at startup.
Differential Revision: https://phabricator.services.mozilla.com/D16140
--HG--
extra : moz-landing-system : lando
Because MSVC compilers only support one architecture, we need to search
"cl" in different toolchain search paths for each of the host and
target, especially when they are different.
Likewise for the library paths for the linker. Ideally we'd pass
-LIBPATH both for host and target, but that has implications for rust
that I don't want to have to figure just now.
Depends on D15263
Differential Revision: https://phabricator.services.mozilla.com/D15264
--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
LLVM_PROFDATA needs the toolchain search dir, per bug 1515579.
Also, most of the options actually don't do anything useful with
artifact builds. In fact, the only one that artifact builds would need
is MOZ_PGO. So we move to options back to toolchain.configure, somewhere
late enough ; except MOZ_PGO, that we move to the top-level
moz.configure (because we don't need a separate file for one option).
Differential Revision: https://phabricator.services.mozilla.com/D16152
--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
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
Because we now set the sysroot include flags early in python configure,
we don't need to set CPP/CXXCPP. We also skip the explicit compiler test
because more complete tests follow anyways.
Differential Revision: https://phabricator.services.mozilla.com/D14380
Summary:
I've chosen linux64-debug since it's the most visible build I usually do, but I
could do another build task or something, or use the static analysis builds, or
what not. Just let me know if there's a better way to do this.
Caveat: This might make updating Rust toolchains a bit more painful. I think
this is better and we should just deal with warnings before updating toolchains,
but I don't know if there'd be strong opposition to that.
Note that this does _not_ affect third-party code since Cargo passes
`--cap-lint warn` automatically for those.
Proof that it works:
* https://treeherder.mozilla.org/#/jobs?repo=try&revision=4ad1e4e1392f71b574cff683e90c7b13bf8781d1
* https://treeherder.mozilla.org/#/jobs?repo=try&revision=57604f92624bbe49037eee87c56fdb6bf2b5017d
Reviewers: #firefox-build-system-reviewers, ted
Reviewed By: #firefox-build-system-reviewers, ted
Subscribers: reviewbot, glandium, ted
Bug #: 1513009
Differential Revision: https://phabricator.services.mozilla.com/D14083
This is required on Mac, where there is a dummy nasm executable
that prints an error if the real nasm isn't found.
Differential Revision: https://phabricator.services.mozilla.com/D12371
--HG--
extra : moz-landing-system : lando
Includes changes to support nasm's stricter include paths.
Supports falling back to yasm if nasm is missing.
Differential Revision: https://phabricator.services.mozilla.com/D9972
--HG--
extra : moz-landing-system : lando
The desired outcome of this change is that we'll set
-Wl,--version-script based on linker kind and not on the output of
$LINKER -v.
This is a cheap way to address a simple problem that has a complicated
ideal solution. The underlying issue is that in some situations, when
targeting Android, a macOS system ld is interrogated to determine if
a cross-compiling linker "is GNU ld" and a particular linker feature
is set in that situation. The macOS system ld doesn't pass the "is
GNU ld" test, and the linker feature isn't set; that causes link
failures, even though the actual linker has nothing to do with the
system ld.
The ideal solution is to test for linker capabilities dynamically. We
do a lot of that in old-configure.in, and we don't do any of that in
toolchain.configure. Rather than start testing in
toolchain.configure, we hard-code: a cheap solution to the immediate
problem.
MinGW suffers somewhat from the opposite problem: the linker "is GNU
ld" (compatible), but the linker checks don't happen at all. We hard-code
for MinGW based on the C compiler instead.
Differential Revision: https://phabricator.services.mozilla.com/D8471
--HG--
extra : moz-landing-system : lando
This patch also changes how pdbs for the ASAN job are copied:
we relax restrictions so that pdbs if present) are always copied out
and add an environment variable MOZ_COPY_PDBS to indicate when we
want to produce pdbs for copying.
The desired outcome of this change is that we'll set
`-Wl,--version-script` based on linker kind and not on the output of
`$LINKER -v`.
This is a cheap way to address a simple problem that has a complicated
ideal solution. The underlying issue is that in some situations, when
targeting Android, a macOS system `ld` is interrogated to determine if
a cross-compiling linker "is GNU ld" and a particular linker feature
is set in that situation. The macOS system `ld` doesn't pass the "is
GNU ld" test, and the linker feature isn't set; that causes link
failures, even though the actual linker has nothing to do with the
system `ld`.
The ideal solution is to test for linker capabilities dynamically. We
do a lot of that in old-configure.in, and we don't do any of that in
toolchain.configure. Rather than start testing in
toolchain.configure, we hard-code: a cheap solution to the immediate
problem.
Differential Revision: https://phabricator.services.mozilla.com/D8471
--HG--
extra : moz-landing-system : lando
While we do have some uses of @depends-function comparison in some
templaces, related to host/target, we ought to be using `is` comparisons
rather than `==` anyways, so we switch those, and prevent other kinds of
comparisons being used at all.
This unveils the one noted in
https://phabricator.services.mozilla.com/D7713?id=21357#inline-30414
(and surprisingly only that one), that we remove entirely since it was
doing nothing in practice. Bug 1492305 will have to add it back in a
proper form.
Differential Revision: https://phabricator.services.mozilla.com/D8501
--HG--
extra : moz-landing-system : lando
Mike Shal
Mike Hommey
Chris Manchester
Razvan Maries
Margareta Eliza Balazs
Narcis Beleuzu
Tom Ritter
Dorel Luca
Emilio Cobos Álvarez
Gurzau Raul
Thomas Daede
Gian-Carlo Pascutto
Cosmin Sabou
Tooru Fujisawa
David Major
Nick Alexander
Benjamin Bouvier