Back when this was added, clang's default mode might have been c++11,
but it's not c++17, and we're effectively downgrading it (which
incidentally causes problems to build libc++).
Differential Revision: https://phabricator.services.mozilla.com/D137255
It is currently enabled automatically because libxml2 is detected, but
we want to be sure it's not accidentally disabled.
Differential Revision: https://phabricator.services.mozilla.com/D136840
`extra_targets` was used for the aarch64-linux compiler runtime, which
moved to a separate task in bug 1690757, and `android_targets` was used
for android compiler runtimes, which moved to separate tasks in
bug 1690973.
Using separate tasks is now the prefered way to build compiler runtimes,
os we won't need these options.
Differential Revision: https://phabricator.services.mozilla.com/D136822
When cmake fails during the clang build, we currently print out the
contents of CMakeOutput.log and CMakeError.log because they may contain
something useful to debug what happened. Unfortunately, because the
treeherder log parser doesn't see the actual error, it reports the
normal error that are part of the logs as being the errors causing the
failure, the first one of which is a check whether malloc/malloc.h is a
thing, which it is not, and that's normal.
So instead of printing them out, we provide the files as artifacts.
Differential Revision: https://phabricator.services.mozilla.com/D134999
- stage 1 is building clang with whatever compiler is available
- stage 2 is building clang with the clang built during stage 1
- stage 3 is building clang with the clang built during stage 2. It's
only useful when it's actively compared against stage 2, or when
there's a stage 4.
- stage 4 is building clang with the clang built during stage 3, with the
profile generated during stage 3, when stage 2 produced a clang with
instrumentation enabled.
We're not actively comparing the output of stage 2 and 3 when not doing
PGO, so it's not useful to do 3-stage builds.
Differential Revision: https://phabricator.services.mozilla.com/D133314
Short of solving this by fully embracing the monorepo build and removing
the projects/ workarounds (which will also require a compat more with
older clang versions we still build with the same script), we can solve
the bustage with a small hack.
Differential Revision: https://phabricator.services.mozilla.com/D131458
Using the sysroot with GCC requires some unnecessary complication, and
we don't really care if the first stages are not using the sysroot.
Differential Revision: https://phabricator.services.mozilla.com/D125161
Building sanitizers in older versions of clang emit errors when built with
newer GCC because of some narrowing conversions. We only really need the
sanitizers in the final stage anyways, so we force-disable them (and
everything else that might enable "sanitizer-common") in early stages.
Building the lli tool (also used in tests) fails as well, and we don't
need it until the final stage (where we need it to ship it).
Differential Revision: https://phabricator.services.mozilla.com/D125159
It's an unnecessary difference with our other clang builds. It looks
like it was cargo-culted from some external script. It makes the
android-cross clang different in the way it finds e.g. compiler
runtimes, some of which are in lib/, and others in lib64/, and only the
latter are actually found.
Differential Revision: https://phabricator.services.mozilla.com/D123017
The wasi-sysroot toolchain contains both a sysroot for wasi and a
compiler-rt for clang. That makes it impractical to use as a
bootstrapped sysroot for wasm32-wasi builds of Spidermonkey.
We thus split the toolchain in two, one for the compiler-rt and one
for the sysroot. Ideally, the compiler-rt one would avoid building
clang/llvm the same way the sysroot one does, but that leads to
a case of chicken-and-egg, because the compiler-rt is needed to build
the clang toolchain. Eventually, the clang build would be split from
the addition of the compiler-rt, but we're not there yet.
Differential Revision: https://phabricator.services.mozilla.com/D122402
Clang >= 11 ignores PYTHON_EXECUTABLE entirely (and uses python3, which
is not even what we pass, but that's actually fine), and all the build
tasks we have on older versions find the python executable they need on
their own.
Differential Revision: https://phabricator.services.mozilla.com/D120049
- we needed -gcc-toolchain to pick C/C++ standard headers from the right
version of GCC, but we now have them in the toolchain sysroot (bug
1719207), so we can use that instead.
- we needed LD_LIBRARY_PATH when clang was built on an older version of
Debian, but that was changed in bug 1694775.
Differential Revision: https://phabricator.services.mozilla.com/D119135
We have a separate binutils toolchain already, and the only remaining
use of the binutils part of the the GCC toolchain is for the gold plugin
headers for clang, which we can add to the toolchain sysroot.
Differential Revision: https://phabricator.services.mozilla.com/D119133
We've been building clang with SDK 10.12 since bug 1680152, but the
build-clang script is still assuming we're building with an older one.
Differential Revision: https://phabricator.services.mozilla.com/D105266
When using the --sysroot argument to clang, clang changes where it
searches for libraries in its own directory, and excludes the lib and
lib32 subdirectories. So we need to move the gcc files to a place where
it does look (and that it also looks without --sysroot).
We however still keep a copy of libstdc++ in the lib directory for
runtime purposes.
Differential Revision: https://phabricator.services.mozilla.com/D104123
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
LLVM 11 introduces a hard requirement for SDK 10.12 in order to build for Mac. We want to keep building older LLVMs with 10.11 though, so this patch adds some flexibility so that build-clang can make use of whatever SDK package a particular task pulls from tooltool (but still requesting a deployment target of 10.11).
Differential Revision: https://phabricator.services.mozilla.com/D82621
clang/LLVM's build scripts can turn these on on their own, but explicitly
setting what we want is better than guessing. The change is not huge, maybe
~2-3% on the major shared libraries (`libclang`, `libclang-cpp`, `libLLVM`),
about 1% on the overall `.tar.zst` size, but every little bit counts, right?
Differential Revision: https://phabricator.services.mozilla.com/D82896
