Update to the point release. These are repacks of the
upstream builds for 1.15.1 stable with appropriate
libstd builds for each target.
This incorporates the -fPIC fix for linux32 so we can
use upstream builds instead of our patched toolchain.
It also corrects the signature of vec::IntoIter::as_mut_slice
which was incorrect in 1.15.0.
MozReview-Commit-ID: JvEdGPwgS03
--HG--
extra : rebase_source : 9edd9970d8328274311493c2c3c4fffa97b258a9
Use a custom build of rust 1.15.1 with an additional bump of the
gcc crate to 0.3.43 to pass -fPIC to the C compiler on i686-linux.
While 1.15.1 was tagged today, there's some question as to whether
it would be released from the tag or if the tag would be moved
to incorporate this fix.
This works around the issue with text segment relocations with
the 1.15.0 stable release. For more information see the upstream
issue at https://github.com/rust-lang/rust/pull/39523
MozReview-Commit-ID: 83IxtJeJxlh
--HG--
extra : rebase_source : 8deda9058c77a98c65a46949768702c56296d9d4
Repack of the upstream builds of the rust 1.15.0 stable release.
MozReview-Commit-ID: KDjkSQSFrFA
--HG--
extra : rebase_source : 7ca562b3d1cc4d051d9cfc25ef14fbbe2dbd77bb
CLOSED TREE
Backed out changeset 158233bce738 (bug 1197325)
Backed out changeset b5ac3fa0bbe7 (bug 1197325)
Backed out changeset 55a8ad127517 (bug 1197325)
Taskcluster builds don't yet support uploadsymbols, so we need to allow
the beta & release mozconfigs for OSX universal builds to support
setting MOZ_AUTOMATION_UPLOAD_SYMBOLS to 0 rather than always overriding
it to 1.
MozReview-Commit-ID: 5pO0sYsQMJq
--HG--
extra : rebase_source : 301ba8c58fd433f023152d8c2f4ad25e5cbd654e
It turns out that running makecab to compress PDB files takes a significant
amount of time in the buildsymbols step. I wrote an implementation of
makecab in Rust that implements only the subset of features we use and
it's significantly faster:
https://github.com/luser/rust-makecab
This patch adds a makecab check to moz.configure, adds a release build of
the makecab binary to the Windows tooltool manifests, points the build at
it from mozconfig.win-common, and changes symbolstore.py to use MAKECAB
from substs instead of calling `makecab.exe` directly.
MozReview-Commit-ID: 76FHLIZFCXS
--HG--
extra : rebase_source : af4cf2e4db4607ec9329b2811cc0175d3e113b66
It turns out that running makecab to compress PDB files takes a significant
amount of time in the buildsymbols step. I wrote an implementation of
makecab in Rust that implements only the subset of features we use and
it's significantly faster:
https://github.com/luser/rust-makecab
This patch adds a makecab check to moz.configure, adds a release build of
the makecab binary to the Windows tooltool manifests, points the build at
it from mozconfig.win-common, and changes symbolstore.py to use MAKECAB
from substs instead of calling `makecab.exe` directly.
MozReview-Commit-ID: 76FHLIZFCXS
--HG--
extra : rebase_source : dc0014e9ad8d242fe14b18cc90ad477445f666dc
Repacks of the upstream builds of rust 1.14.0 stable release.
MozReview-Commit-ID: B5DclOLeBjM
--HG--
extra : rebase_source : 67db55dd62d6177b30ace5008edc680f95c6ed22
Collect common options used in artifact build tests in a single
mozconfig so they can be set more consistently.
Use this to make unsetting toolchain defines universal in these
tasks, fixing fallout from bug 1283898 which defined CARGO and
RUSTC everywhere, conflicting with --disable-compiler-environment
just like CC and CXX were conflicts in some artifact tasks.
MozReview-Commit-ID: 4SbxByjClQb
--HG--
extra : rebase_source : d8a48fd2192ceb5ece76c827e2243ae784b991cb
The --disable-compile-environment configure option used by
the artifact builds removes all support for toolchains,
including setting paths for them with environment options.
Unset the RUSTC and CARGO vars inherited from mozconfig.rust
in the artifact mozconfigs to accommodate the invalid option
check, just like we do for the CC and CXX options.
MozReview-Commit-ID: IwPetRaIY25
--HG--
extra : rebase_source : 37fb4bf9e69d3082cc0ed6b0013e6363a7e8e8e5
Tasks calling these generally use tooltool and the hazard
manifest to provide toolchains, but the setup job doesn't
they don't use a mozconfig to configure paths, and the analysis
job uses a different TOOLTOOL_DIR.
The build calls configure, which defaults to --enable-rust,
so we need to add the correct rust toolchain path to the
environment like we do for C++.
MozReview-Commit-ID: gFnZ0SK1f7
--HG--
extra : rebase_source : f7cabb5b15551f5b00ff8271ceddeb4b47146c03
Update the linux64 releng tooltool manifest to to same
repack of rustc 1.14.0-beta.2 with support for x86_64 and
i686 targets we're using for the linux32 builds.
This is necessary for --enable-rust to work on 32-bit
Spidermonkey cross builds.
MozReview-Commit-ID: 1xfOBHOZ4iB
--HG--
extra : rebase_source : a1ec78464be1d82929c25c35fe18b8f9e4fae148
Include mozconfig.rust in the common mozconfig so all jobs
will have the same rust config.
Automation mozconfigs all inherit from mozconfig.common,
so we can include mozconfig.rust there and not need it
anywhere else.
Remove --enable-rust from mozconfig.rust now that it's
the default. We only need the RUSTC and CARGO path
variables so jobs can find the toolchain installed from
the tooltool manifest. Also some automation jobs reject
the configure option if we set it unconditionally.
The --enable-rpath comment is no longer necessary; rust has
been consistently built this way for some time.
MozReview-Commit-ID: 2IeIIIinnPL
--HG--
extra : rebase_source : 79dadcc5ed13f2db312042d755a57698f267e902
Jobs using these additional tooltool manifests need an appropriate
rust toolchain when rust code is enabled.
MozReview-Commit-ID: YM7yjJk3w5
--HG--
extra : rebase_source : d98f3a9c2b1bcba337eedcaa06125ac5fb9dfd40
The universal l10n-mozconfig includes build/macosx/mozconfig.common,
which sets up CC/CXX to point to the tooltool version of clang. We need
the tooltool version in order to build with the newer compiler features
that we use.
The additional changes to the mozconfig are done to make the macosx64
version match what we had in macosx-universal.
MozReview-Commit-ID: AnjuC904vqH
--HG--
extra : rebase_source : 71bea472621901498ad55490d2126568f54abe4d
Official Mozilla builds no longer support non-SSE2 x86 cpus,
so we can use the default i686 rust target here. This allows
better code generation and removes a dependency on the extra
i585 rust std library.
MozReview-Commit-ID: BHrm4tieIym
--HG--
extra : rebase_source : e791068b6128b9f3153b9c85ebd8551d583c2bc7
These are all based off of the win32 debug-static-analysis config. I
chose to use separate configs because the debug-static-analysis config
is currently being used for other purposes. We'll need to consolidate
after clang-cl and windows static analysis builds are running on
automation.
Update tooltool manifests to repacks of upstream builds of
rustc 1.14.0-beta.2 (e627a2e6e 2016-11-16)
cargo 0.15.0-nightly (a9c23dd 2016-11-15)
for the relevent hosts and target platforms.
We prefer to use stable rust but this bump gets us debuginfo
for the rust standard library on all platforms, which we hope
will improve crash reporting (bug 1268328). That is higher
priority. The rust 1.14 version should be in stable release
before Firefox 53 goes to Aurora, so we'll still stabilize
and ship with stable rust.
This build also contains the fix for the arm code generation
bug blocking update from 1.12 on android, so we can use 1.13
language features in Firefox 53. For more information, see
https://github.com/rust-lang/rust/pull/37815
This doesn't update the native MacOS build because of an
openssl link issue with cargo. This is resolved upstream
for rust 1.15; getting that ported to a later 1.14 beta is
tracked in https://github.com/rust-lang/rust/issues/37969
MozReview-Commit-ID: JbJTd4D7VOu
--HG--
extra : rebase_source : 0690f3d4443f3fc7f224f051f910de92c54b8f60
Run the tooltool manifests through a python script to read the
json as an OrderedDict and when write it back out with normal
tooltool formatting options. This regularizes the whitespace,
fixing trailing spaces written by older versions of the python
json serializer, dos-vs-unix line endings, and regularizing
opening '[{' and closing '}]' to be on separate lines.
The android manifests have a 'versions' key which has indenting,
unlike the rest of the files. I've left that as-is.
MozReview-Commit-ID: EVW1YlgRJJL
--HG--
extra : rebase_source : 40c1992090807dc40495ebacb37ee358c1d6a6f1
This patch does a few things:
1) Change all the in-tree tooltool manifests to contain sccache2 instead of the existing Python sccache
2) Change mozconfig.cache to point at sccache.
3) Lightly tweak the --with-cccache configure option to support sccache, and detect whether we're using ccache or sccache and set an option appropriately.
4) Add a MOZ_SCCACHE_VERBOSE_STATS option, and add a target in the top-level Makefile to make sccache spit out its stats at the end of the build. This is useful to see the cache hits/errors until we get something better.
5) Add MOZ_USING_SCCACHE to the build telemetry. Not that I think it will be immediately useful, but for future use.
MozReview-Commit-ID: 9lrdLwNj5Bm
--HG--
extra : rebase_source : d323457df10d0ee0ac5811940e518d9422a7e070
We add opt and debug mozconfigs that enable stylo.
We define 2 new mozharness build configurations for stylo builds. These
occur only on Linux64 for the moment.
The mozharness configs are mostly copypasta. This is how you do things
in mozharness land.
MozReview-Commit-ID: 99XNOymw9Dx
--HG--
extra : rebase_source : d89ddd907ed96697f62637859f6f719601e03b01
We no longer make use of these, instead using the cargo included
in the rustc packages.
MozReview-Commit-ID: Dr9q0g7amEk
--HG--
extra : rebase_source : d4e46a02ef34ad070a2934a1af88e26cdf97bd6f
Update builders to repacks of the upstream stable builds.
We did not update the Android build because 1.13.0 has a
code-generation bug on Android.
MozReview-Commit-ID: Ju0CI8JYLbz
--HG--
extra : rebase_source : aa7c77dd9b02717f7b9763667633ccb6ed994768
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.
Upload symbols when --enable-artifact-build-symbols is specified.
Add --enable-artifact-build-symbols to artifact config for linux, linux64,
win32, win64, macosx64.
MozReview-Commit-ID: LpuwfzWXPBH
--HG--
extra : rebase_source : 137466aa3c8c327cf1932e012927fceb451d82ab
Move to a late beta of 1.12 to work around the llvm-dsymutil
crashes from running `./mach buildsymbols` with the rustc 1.11
output on current m-c. See bug 1301751 for details.
MozReview-Commit-ID: 1gbAGLOxkaO
--HG--
extra : rebase_source : 14ce15d9890a9e052f67bb795de209220179d70e
These builds can be run on taskcluster to obtain per-test (JSDebugger) code coverage with the linux64-jsdcov build and overall (GCOV) code coverage with the linux64-ccov build. The linux64-jsdcov build also needed to have leak checking disabled for debug mode.
MozReview-Commit-ID: ASgrU2X7RQV
--HG--
extra : rebase_source : b2098e4d01039edd6cff37f3e6a26c2ed3d3d3ba
These builds can be run on taskcluster to obtain per-test (JSDebugger) code coverage with the linux64-jsdcov build and overall (GCOV) code coverage with the linux64-ccov build. The linux64-jsdcov build also needed to have leak checking disabled for debug mode.
MozReview-Commit-ID: ASgrU2X7RQV
--HG--
extra : rebase_source : af40a6e582665ffcb575092586731f595a362ae4
Visual Studio 2015 Update 3 has been out for a few months. It appears
stable. So let's start using it.
As part of this, we also update the Windows SDK to the version
corresponding with the Windows 10 Anniversary Update (10.14393.0).
MozReview-Commit-ID: C36sRlKqa8t
--HG--
extra : rebase_source : 2fd46d6053d3eaf62dd8b2b291881c5172cc6056
Update linux32 tooltool manifest to use a gecko build of rustc and cargo
for x86_64-unknown-linux-gnu host targeting both x86_64 and i586.
rustc built with --enable-llvm-static-stdcpp --disable-docs
--enable-debuginfo --release-channel=stable from 'stable' branch
rust 1.11.0 (commit 9b21dcd6a89f38e8ceccb2ede8c9027cb409f6e3)
Pass --target i585-unknown-linux-gnu when building for 32-bit linux.
We mostly want this for official builds, but Debian needs it too,
in both cases to support old machines without SSE2 instruction set
support, so while it means developers will have to `rustup target add
i585-unknown-linux-gnu` when building for this architecture that is
not a common task (most linux devs will be on 64-bit) and it reduces
variance and surprise if binaries are distributed.
MozReview-Commit-ID: 3mAjWxYGpwZ
Repacks of upstream builds of rust 1.11.0 stable with std libraries
for the appropriate targets. Remove the separate rust-std package
references since the new repacks include the necessary targets.
Also update clang and hazard builds to the latest toolchain.
MozReview-Commit-ID: K7oBxQZnLPu
--HG--
extra : rebase_source : 9f339ff52e9e2f6c28d4bb7a734b9f0eae43a47a
Update tooltool cargo packages to the 2016 August 31 nightly
build. These have source-redirection support needed by the
stylo project but not available in stable cargo yet.
Repacks of the upstream build cargo 0.13.0-nightly (e713e7f 2016-08-31).
MozReview-Commit-ID: 7Ejckg9dPZy
--HG--
extra : rebase_source : bae84e6336feb259954c093dc377e6504e973682
We update the rust compiler for cross build as well as use rust-std for
mac.
MozReview-Commit-ID: JgqKTtqXKqK
--HG--
extra : rebase_source : 21286ecdf28a0cf2f8a5e7e81609b418c83b1f15
Update clang for the built version shipping libc++. This is primarly
intended to fix Mac OSX cross builds, but for a matter of consistency,
we update it for all clang builds done in a Linux host.
The ld that we use for Mac builds is old (Xcode circa OS X 10.7), and
also crashes in various ways when we try to use newer Rust versions
and/or pass options to make the linker work with newer Rust versions.
To mitigate this, let's build with a newer linker, compiled from:
https://github.com/tpoechtrager/cctools-port
We use this port, rather than the packages from opensource.apple.com,
because the packages from Apple have decidely non-intuitive build
systems, and require some hacking to get to build. This port, in
contrast, is simply built with:
CFLAGS='-mcpu=generic -mtune=generic' ./configure --target=x86_64-apple-darwin11
env MACOSX_DEPLOYMENT_TARGET=10.7 make
and the resulting x86_64-apple-darwin11-ld is renamed as 'ld' and
packaged up for automation's purposes.
However, since this linker is newer, it also produces bits of Mach-O
that our older build tools don't understand. Fortunately, we can pass
appropriate options to the linker to turn off generation of those Mach-O
bits.
- Update the tooltool manifests to use the new package.
- Update mozconfig paths to reflect MSVC tooltool package changes.
--HG--
extra : rebase_source : 2f2da35ec1d1b3fb5ca9210951d9ac3a38a2bd75
Repacks of upstream builds cargo 0.13.0-nightly (664125b 2016-07-19)
for each host platform. Unpacks into cargo/bin/cargo.
This version supports `cargo build --frozen` to disallow
network access during the build.
MozReview-Commit-ID: IihpDlqxPx6
Repacks of upstream rust 1.10.0 stable builds with cargo and std for necessary target architectures.
MozReview-Commit-ID: CgPukGLz4Dv
--HG--
extra : rebase_source : e393c1f0aa4e8d14861ed5bb76f1ac73bfcab444
Gecko builds of rustc and cargo. x86_64-unknown-linux-gnu host
targeting both x86_64 and i686.
rustc built with --enable-llvm-static-stdcpp --disable-docs
--enable-debuginfo --release-channel=stable from 'stable' branch
rust 1.10.0 (commit cfcb716cf0961a7e3a4eceac828d94805cf8140b)
cargo built from 'master' branch
cargo 0.11.0-119-g9f1ffdd (commit 9f1ffdd69b9fc564431e027a5043b303c7ec3808)
MozReview-Commit-ID: 4hq6dan8pk0
Needed because buildbot clones/checks out from the repo head (of default)
and then updates to the rev for the nightly we're pulling, which can cause
CLOBBER file changes to initiate an unwanted clobber of the object directory
where we just pulled the nightly binary from. Even when CLOBBER hasn't actually
been touched in the changeset range we're looking at between nightlies.
MozReview-Commit-ID: 154d2iZeHgd
--HG--
extra : rebase_source : 504b821955a870cabf6fc727d13e44a33aabb45c
Something similar was done in bug 1278718 for ASan builds, because of
indirect dependencies on libstdc++ being picked by the linker and
leading to linkage failure with the older binutils from the CentOS 6
image we use to do desktop builds.
Build slaves on automation are based on Centos 6, which doesn't have a
recent enough version of libstdc++ for our new requirements. But since
we're building with a recent GCC or clang with its own libstdc++, we do
have such a libstdc++ available somewhere, and the compiler picks it
when invoking the linker.
Problems start happening when we execute some of the built programs
during the build, like host tools (e.g. nsinstall), or target programs
(xpcshell, during packaging). In that case, we need the compiler's
libstdc++ to be used. Which required adding the GCC or clang library
directory to LD_LIBRARY_PATH.
Unconveniently enough, the clang 3.5 tooltool package we're using for
ASAN builds until we can update to at least 3.8 (bug 1278718) doesn't
contain libstdc++.so. So for those builds, pull the GCC package from
tooltool as well, and pick libstdc++ from there.
Custom build of rust 1.9.0 stable for gecko with
--enable-llvm-static-stdcpp --disable-docs --release-channel=stable
--enable-debuginfo for x86_64-unknown-linux-gnu targeting
x86_64-unknown-linux-gnu and i686-unknown-linux-gnu.
MozReview-Commit-ID: 1ycJzrPGkeA
We were using 1.9 beta for i586 support. Now that it's no longer
necessary we can revert to the stable release.
This is a repack of the 1.8.0 upstream stable build targetting
only i686-pc-windows-msvc.
MozReview-Commit-ID: 7ieQ9steK5k
We were using 1.9 beta for i586 support. Now that it's no longer
necessary we can revert to the stable release.
This is a repack of the 1.8.0 upstream stable build targetting
only i686-pc-windows-msvc.
MozReview-Commit-ID: 7ieQ9steK5k
Pass --enable-rust for official Firefox builds on 32-bit
linux. This enables it for all channels, just like other
platforms.
MozReview-Commit-ID: BCQrOVkGNtJ
This is the same repack of the upstream 1.8.0 stable build
for x86_64-unknown-linux-gnu hosts plus the i686 and
x86_64 std libraries used for the linux64 builds.
MozReview-Commit-ID: Gfd9YkNVe4K
compare-mozconfigs-wrapper.py complains that mozconfig.rust
is included in mozconfigs\win64\release but not
mozconfigs\win64\release even though it is.
We've let this ride the trains for other archs. Should do so
for win64 as well.
MozReview-Commit-ID: D7dS9femsBj
--HG--
extra : rebase_source : 1bb5919009e005f29420fdff6cc472ae104b8421
Rust 1.8 added unwind support. but 1.9 is the first release
with i586 target support without SSE2 instructions in the
standard library, which we need for compatibility with older
machines, so we need to stay on 1.9 until it's in stable release.
This is a repack of the upstream 1.9.0-beta.1 compiler build
for i686-pc-windows-msvc hosts and both i686 and i586 targets.
MozReview-Commit-ID: Ed6ND7NE1F1
--HG--
extra : rebase_source : 82587d7c2f1798f1ceb5dab708740e2bdfb62af3
This is a repack of the upstream 1.8.0 stable compiler build
for x86_64-pc-windows-msvc hosts and the corresponding std
library.
MozReview-Commit-ID: 6vHDTQgeKBW
--HG--
extra : rebase_source : 90f7daf3defdcd0967dae4a8a2827a143e7b2b65
This is a repack of the upstream 1.8.0 stable build
for x86_64-unknown-linux-gnu hosts plus the i686 and
x86_64 std libraries.
MozReview-Commit-ID: F6q9Y51ow8U
--HG--
extra : rebase_source : 50538ed05bf744f6513f57d2847f751dcc8c40e1
Ideally, we'd use the tarballs from
http://llvm.org/releases/download.html but I didn't feel like modifying
the script more than I already did to make it work at all (bug 1262735).
The new tarball for Linux was built on
https://tools.taskcluster.net/task-inspector/#LCUn8aEgTBeRJ11a3qTlDQ/0
The new tarball for Mac was built on a loaner, after installing cmake
and ninja, as well as building ld64 127.2 from source because the
installed version would assert while building clang. The latter required
manually adding some missing headers to /usr/include. TSAN was also
disabled because it requires APIs that are not available on the OSX
version on the build slaves (e.g. pthread_introspection_hook_install).
Building clang also required using a mac clang from tooltool, the system
one lacking support for atomics.
At the same time, we improve things slightly by deriving HOST_CC from CC
in a smarter way, as well as CXX from CC, which we weren't doing
previously.
Many related things are not moved at the same time to keep the patch
somehow "small".
Update win32 builds to use a Repack of today's (2016 April 1)
rustc nightly for i686-pc-windows-msvc host and
i586-pc-windows-msvc target.
This should properly support machines without sse2 instructions.
This commit switches Windows builds from Visual Studio 2013
to Visual Studio 2015 Update 1.
Previously, Visual Studio was installed on the builders as part
of the base system image. Starting with this commit, we obtain
Visual Studio from a pre-generated, self-contained archive
containing the executables, Windows SDK, and other support
files. This means that new Windows toolchains can be installed
without having to modify configuration of machines in automation!
The mozconfigs for Visual Studio 2015 are a bit different from
existing mozconfigs.
Because it appears to be completely redundant and not necessary,
the LIBPATH variable has been dropped.
The order of paths in PATH, LIB, and INCLUDE has changed. The new
order more accurately reflects what would be defined by
vcvarsall.bat.
As part of switching to Visual Studio 2015, the Universal CRT is
now required. So, the 2015 mozconfigs export WIN_UCRT_REDIST_DIR
to define the location to those files.
The switch to Visual Studio 2015 also involves the switch from
the Windows 8.1 SDK to the Windows 10 SDK. However, we still
target an old version of Windows, so this hopefully shouldn't
have any significant fallout.
It's worth noting that switching to Visual Studio 2015 makes
builds - especially PGO builds - significantly faster. Our
PGO build times in automation are ~1 hour faster. Our regular
builds appear to be a few minutes faster.
MozReview-Commit-ID: Pa5GW8V87Q
--HG--
extra : rebase_source : bff4fad17f781d8d21bdb941bdd500955d1e9f08
extra : amend_source : faa3038c290fdf5cdd3e24a45ba2a37490f68c17
extra : source : 56b27306d3257445f70374aa78fc5bd42ef300ce
We're still using a i686-pc-windows-msvc rust stdlib,
but now that bug 1255869 we have runtime protection against
calling the sse2 code it contains.
Reverts bug 1253456.
--HG--
extra : rebase_source : 28c7399eb9f90f2865c41eb394a5949e05a632ff
Build from source of rust 1.7.0 stable configured with
--enable-llvm-static-stdcpp --disable-docs --release-channel=stable
and --target=x86_64-unknown-linux-gnu,i686-unknown-linux-gnu
using the quay.io/rust/rust-build-gecko docker image.
https://github.com/rillian/rust-build commit e4902d5a072b.
https://tools.taskcluster.net/task-inspector/#ZSNL6FCoT7mWahGGxpWCOQ/0
--HG--
extra : rebase_source : 134c3a5d10c12b7e0b62b617f193b024d0b5e417
Repacked official beta builds of rustc 1.8 and the std library.
We still need the unwind fixes in 1.8, but want to update
now that version is in beta. This doesn't address the sse2
issues with the std library code; see bug 1253202.
--HG--
extra : rebase_source : 8cf31b8946418199aa74499fcdfa40b7ef2b2161
Until we can address the sse2 code generation issue,
disable rust on win32 nightly, beta, and release builds.
Leave it enabled in debug builds for testing convenience.
This uses a repacked version of the upstream 1.8 nightly
builds. We need 1.8 for WinXP support, but it's safe to
use nightly until this stablises because other platforms
are using stable rust and will catch any nightly-only
feature use.
For these builds I used the channel-rustc-nightly manifest instead
of the older channel-rust-* manifest, to get the separate std packages.
tar xf rustc-nightly-i686-pc-windows-msvc.tar.gz
rustc-nightly-i686-pc-windows-msvc/install.sh --prefix=rustc/
tar xf rust-std-nightly-i686-pc-windows-msvc.tar.gz
rust-std-nightly-i686-pc-windows-msvc/install.sh --prefix=rustc/
tar cjf rustc.tar.bz2 rustc/*
We're already riding the trains on macosx and linux64, enabling
this for all channels this avoids having to whitelist the config.
This uses a repacked version of the upstream 1.8 nightly
builds. We need 1.8 for WinXP support, but it's safe to
use nightly until this stablises because other platforms
are using stable rust and will catch any nightly-only
feature use.
For these builds I used the channel-rustc-nightly manifest instead
of the older channel-rust-* manifest, to get the separate std packages.
tar xf rustc-nightly-i686-pc-windows-msvc.tar.gz
rustc-nightly-i686-pc-windows-msvc/install.sh --prefix=rustc/
tar xf rust-std-nightly-i686-pc-windows-msvc.tar.gz
rust-std-nightly-i686-pc-windows-msvc/install.sh --prefix=rustc/
tar cjf rustc.tar.bz2 rustc/*
Now that we have cross-compilation tooltool packages for OS X, we can
use the common mozconfig to enable Rust on all OS X builds, regardless
of host OS.
