While here, since the tooltool call from the cctools build scripts was
verbose, make the one in tooltool-download.sh verbose. It will benefit
the other things using tooltool-download.sh, making debugging easier
when one needs to look at the tooltool download logs...
Also use the same cctools as cross-mac builds of Firefox.
Do dummy changes to the corresponding build scripts so that the builds
are force triggered (toolchain builds are not triggered automatically
when the tooltool manifest they use changes yet).
The cctools-port build scripts were pulling and building the master branch
of the cctools-port repo, which means they'd build whatever was there
when they get triggered. I think this was copied from my build-cctools
script which did the same thing, so it's my fault in the end! This patch
pins a revision in the script so we'll build the same thing until we
explicitly update.
I also fixed the scripts to use git instead of tc-vcs, since tc-vcs prints
misleading error messages, and nothing else uses that anymore.
Finally, I removed the build-cctools script, since all the builds are using
cctools-port now so it doesn't serve any useful purpose.
MozReview-Commit-ID: 5myqHS4duor
The latest upstream version produces .dmg files that have fsck errors,
and some versions of OSX complain that the image is corrupted. The
previous version of libdmg-hfsplus that we were using (1d72dd62a)
doesn't have fsck errors, but it also doesn't preserve file permissions.
Our fork is based on the older version and backports the file permission
commits.
MozReview-Commit-ID: Bjwy6MJ98Ud
There's not a single well-maintained fork of libdmg-hfsplus, but there are
scattered forks with various fixes. The fork + branch I've chosen here
seems to have collected the most fixes, including a specific fix we need
for repacking DMG files on Linux:
5c92af354b
MozReview-Commit-ID: 3RB6gfgQmCA
CLOSED TREE
Backed out changeset 158233bce738 (bug 1197325)
Backed out changeset b5ac3fa0bbe7 (bug 1197325)
Backed out changeset 55a8ad127517 (bug 1197325)
It doesn't seem good to tie ourselves to the Gecko tooltool manifest for
building clang-cl; we want to stick with something we can update on
clang-cl's schedule, not Gecko's.
We cannot depend on a fixed location for cl.exe in a taskcluster world.
We therefore need to make our build-clang.py script accomodate relative
path names for cc/cxx and assume those are binaries that should be
looked up on PATH.
We also need to modify the Linux build script so that the virtualenv is
used to look up the new 'which' package.
There are a number of changes here:
- Taskcluster machines don't have MSVC installed, so we have to setup all
the MSVC infrastructure ourselves;
- Gecko contains useful Python packages to use, so we need to setup a
python virtualenv to have access to those. Fortunately, mach handles all
of that for us;
- We need to add build tools to our PATH, as they are not pre-installed;
- We need to define UPLOAD_PATH ourself.
The build-clang-windows.sh is basically an exact copy of the Linux one
at the moment; we'll fix it up for all the Windows-specific taskcluster
bits in a future commit.
