f410692238
Before bug 1915568, we didn't have symbolic links in the clang artifact. That was an unexpected side effect, but supporting unpacking toolchain artifacts with symbolic links has been a longstanding thing I've wanted to fix, unlocking Linux and Mac cross-compiles on Windows (e.g. sysroot artifacts contain symbolic links). The clang situation is a good occasion to finally do it. It's also somehow desirable to keep clang with symbolic links, as it makes the toolchain artifact smaller. When a tarball contains symbolic links, the python tarfile module ends up trying to seek in the tar, which doesn't quite work when the tar is a stream (which it is when decompressing at the same time). We wrap TarFile so as to handle the symbolic link situation ourselves, and when we can't create symbolic links, we instead create a copy of the file the link points to. Differential Revision: https://phabricator.services.mozilla.com/D221282
This directory contains common Python code. The basic rule is that if Python code is cross-module (that's "module" in the Mozilla meaning - as in "module ownership") and is MPL-compatible, it should go here. What should not go here: * Vendored python modules (use third_party/python instead) * Python that is not MPL-compatible (see other-licenses/) * Python that has good reason to remain close to its "owning" (Mozilla) module (e.g. it is only being consumed from there). Historical information can be found at https://bugzilla.mozilla.org/show_bug.cgi?id=775243 https://bugzilla.mozilla.org/show_bug.cgi?id=1346025