Switches from `buildconfig.substs` to `bootstrap_toolchain` for the repackage job
Refactors mozpack/dmg to not depend on the environment; Moves path resolution of tools up to `mozbuild.action.{make_dmg|unpack_dmg}`
Update syntax to python 3.7+
Differential Revision: https://phabricator.services.mozilla.com/D163129
Switches from `buildconfig.substs` to `bootstrap_toolchain` for the repackage job
Refactors mozpack/dmg to not depend on the environment; Moves path resolution of tools up to `mozbuild.action.{make_dmg|unpack_dmg}`
Update syntax to python 3.7+
Differential Revision: https://phabricator.services.mozilla.com/D163129
This had been attempted in bug 1747532 but failed for some reason and we
limited it to local builds with clang >= 13. Now enable by default on any
build with clang >= 15.
Differential Revision: https://phabricator.services.mozilla.com/D156267
Because the relevant SDK is not installed on the mac workers, we pull it
via fetches and adjust the plain build mozconfig as well as mozconfigs
for rusttest, grouping most things in build/macosx/mozconfig.common.
And because the SDK itself now has all the relevant headers, we don't
need the old check for system C++ headers (which also happens to have
outdated instructions)
Differential Revision: https://phabricator.services.mozilla.com/D156280
We keep the older 11.0 and 10.11 SDKs for openh264.
Ideally, we'd rename the SDK directory not to contain its version, but
ld64 actually relies on the directory name to figure out the platform
version when it's not given to it, which it's not. We can make clang do
that, but it's rather involved (because it also requires setting up the
host linker properly, which we don't do), so we just go the easy route
and keep the SDK version in its directory.
Differential Revision: https://phabricator.services.mozilla.com/D156279
It made sense when we did have problems with the one shipped with clang
and needed an explicitly newer version, but that hasn't been true in a
while. On the contrary, we're now using a version older than clang for
no reason other than having forgotten to update it.
Differential Revision: https://phabricator.services.mozilla.com/D124886
The change happened 2 years ago in bug 1571562, which means the script
hasn't hit a llvm-dsymutil crash since then (we would have noticed that
it doesn't produce reproducers if we had recurring llvm-dsymutil crashes).
So before removing the script, fix it, so that if we do need to dig it
up from history, we don't pull a broken version.
Differential Revision: https://phabricator.services.mozilla.com/D124884
Local builds don't use it, and currently the only builds that happen on
macs on automation are not using the clang toolchain, so they're not
going through the first condition, and the remainder of the mozconfig
is essentially no-ops (plus, the only builds on macs on automation that
do use mozconfigs at all are rusttests, for which those settings wouldn't
matter anyways).
Meaning in practice, the mozconfig is not doing anything useful.
Differential Revision: https://phabricator.services.mozilla.com/D122823
In the case of toolchain tasks, the tooltool download script already
extracted the SDK in $MOZ_FETCHES_DIR, so no adjustment was required.
Only a Firefox mozconfig needs adaptation.
Differential Revision: https://phabricator.services.mozilla.com/D104646
And don't set it via mozconfig. The default to /System/Library/PrivateFrameworks
may also not have matched the used SDK previously, so the new default is
better.
Differential Revision: https://phabricator.services.mozilla.com/D97564
This is both for future proofing (fetches could move any time although
they likely won't), and to fix the path on the future Windows PGO
cross builds, where the fetches path is not under $WORKSPACE.
Differential Revision: https://phabricator.services.mozilla.com/D66358
--HG--
extra : moz-landing-system : lando
The remaining uses all need adjustements to in-tree mozconfigs, so they
all need to be done at once.
However, to make things slightly more intelligible, we do this in two
steps. This is step 1: we modify the use_toolchain transform to take care of
the transformation, while keeping the task definitions intact, so that
we only deal with mozconfig and build script adjustements here.
Differential Revision: https://phabricator.services.mozilla.com/D41890
We need a fix from `cctools-port` master for cross-language LTO builds
to work properly on the Mac. Rather than cherry-picking yet another
commit, which would have to deal with a updated `ld64` upstream, we've
opted to go ahead and update directly to upstream.
This choice brings about some significant build changes, as TAPI support
has moved to a different library that is not easily buildable directly.
Differential Revision: https://phabricator.services.mozilla.com/D36636
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
Mike Hommey
Heitor Neiva
Norisz Fay
Sandor Molnar
Marian-Vasile Laza
Cristian Tuns
Nathan Froyd
Mike Shal
Chris Manchester
Oana Pop Rus
Noemi Erli
Csoregi Natalia
Andreea Pavel
Coroiu Cristina