This patch adds a new macOS sdk (15.0) toolchain.
Additionally, the SDK is updated for custom-car builds as those tasks
were previously failing on an outdated SDK.
Differential Revision: https://phabricator.services.mozilla.com/D223250
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
