mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
765eebf064
rust/appveyor.yml

115 lines
5.3 KiB
YAML
Raw Normal View History

Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 11:43:26 -05:00
environment:
appveyor: Use VS2017 for all our images Originally added in #55935 to test build times, this was reverted in #56201 due to a belief that it caused the exit code 259 spurious errors. We've since learned, however, that the 259 exit code is likely not related to this image update as we're getting it in a number of locations now. VS2017 looks like it may be required to compile LLVm in the near future, notably discovered by #58408 where we attempted to update LLVM.
2018-11-13 15:42:05 -06:00
# This is required for at least an AArch64 compiler in one image, and is also
# going to soon be required for compiling LLVM.
APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2017 Preview
Attempt to fix appveyor
2017-07-19 07:57:56 -05:00
# By default schannel checks revocation of certificates unlike some other SSL
# backends, but we've historically had problems on CI where a revocation
# server goes down presumably. See #43333 for more info
CARGO_HTTP_CHECK_REVOKE: false
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 11:43:26 -05:00
matrix:
Move the swap the tools test and cargotest within check-aux. The cargotest job is renamed to tools for clarification.
2017-11-28 09:19:54 -06:00
# MSVC tools tests
CI: Set job names. This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI. - Set `name` for each job in Travis. - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
2019-03-09 17:48:58 -06:00
- CI_JOB_NAME: x86_64-msvc-tools
MSYS_BITS: 64
Upload the toolstate to the remote repository.
2017-12-04 08:31:57 -06:00
SCRIPT: src/ci/docker/x86_64-gnu-tools/checktools.sh x.py /tmp/toolstates.json windows
RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-msvc --save-toolstates=/tmp/toolstates.json --enable-test-miri
Move cargotest to separate jobs on Travis-CI and AppVeyor
2017-09-15 13:31:48 -05:00
More test fixes from rollup
2017-01-19 19:18:12 -06:00
matrix:
fast_finish: true
Requires tools to test-pass if the corresponding submodule is updated. If a PR intends to update a tool but its test has failed, abort the merge regardless of current channel. This should help the tool maintainers if the update turns out to be failing due to changes in latest master.
2017-12-29 10:05:15 -06:00
clone_depth: 2
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 11:43:26 -05:00
build: false
install:
ci: print the appveyor agent version at the start of the build
2019-03-31 16:56:09 -05:00
# Print which AppVeyor agent version we're running on.
- appveyor version
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 11:43:26 -05:00
# If we need to download a custom MinGW, do so here and set the path
# appropriately.
#
# Note that this *also* means that we're not using what is typically
# /mingw32/bin/python2.7.exe, which is a "correct" python interpreter where
# /usr/bin/python2.7.exe is not. To ensure we use the right interpreter we
# move `C:\Python27` ahead in PATH and then also make sure the `python2.7.exe`
# file exists in there (which it doesn't by default).
travis: Make more network requests retryable This commit attempts to move more network operations to being retryable through various operations. For example git submodule updates, downloading snapshots, etc, are now all in retryable steps. Hopefully this commit can cut down on the number of network failures we've been seeing!
2017-02-25 02:00:47 -06:00
- if defined MINGW_URL appveyor-retry appveyor DownloadFile %MINGW_URL%/%MINGW_ARCHIVE%
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 11:43:26 -05:00
- if defined MINGW_URL 7z x -y %MINGW_ARCHIVE% > nul
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 11:36:52 -06:00
- if defined MINGW_URL set PATH=%CD%\%MINGW_DIR%\bin;C:\msys64\usr\bin;%PATH%
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 11:43:26 -05:00
ci: Compile LLVM with Clang 6.0.0 Currently on CI we predominately compile LLVM with the default system compiler which means gcc on Linux, some version of Clang on OSX, MSVC on Windows, and gcc on MinGW. This commit switches Linux, OSX, and Windows to all use Clang 6.0.0 to build LLVM (aka the C/C++ compiler as part of the bootstrap). This looks to generate faster code according to #49879 which translates to a faster rustc (as LLVM internally is faster) The major changes here were to the containers that build Linux releases, basically adding a new step that uses the previous gcc 4.8 compiler to compile the next Clang 6.0.0 compiler. Otherwise the OSX and Windows scripts have been updated to download precompiled versions of Clang 6 and configure the build to use them. Note that `cc` was updated here to fix using `clang-cl` with `cc-rs` on MSVC, as well as an update to `sccache` on Windows which was needed to correctly work with `clang-cl`. Finally the MinGW compiler is entirely left out here intentionally as it's currently thought that Clang can't generate C++ code for MinGW and we need to use gcc, but this should be verified eventually.
2018-04-24 10:34:14 -05:00
# If we're compiling for MSVC then we, like most other distribution builders,
# switch to clang as the compiler. This'll allow us eventually to enable LTO
# amongst LLVM and rustc. Note that we only do this on MSVC as I don't think
# clang has an output mode compatible with MinGW that we need. If it does we
# should switch to clang for MinGW as well!
#
# Note that the LLVM installer is an NSIS installer
#
# Original downloaded here came from
AppVeyor: Update clang-cl from 7.0.0 to 8.0.0
2019-05-08 10:05:02 -05:00
# http://releases.llvm.org/8.0.0/LLVM-8.0.0-win64.exe
Update all s3 URLs used on CI with subdomains Ensure that they're all forwards-compatible with AWS updates happening next year by ensuring the bucket name shows up in the domain name. Closes #61168
2019-05-28 15:20:43 -05:00
- if NOT defined MINGW_URL appveyor-retry appveyor DownloadFile https://rust-lang-ci2.s3.amazonaws.com/rust-ci-mirror/LLVM-8.0.0-win64.exe
AppVeyor: Update clang-cl from 7.0.0 to 8.0.0
2019-05-08 10:05:02 -05:00
- if NOT defined MINGW_URL .\LLVM-8.0.0-win64.exe /S /NCRC /D=C:\clang-rust
ci: Compile LLVM with Clang 6.0.0 Currently on CI we predominately compile LLVM with the default system compiler which means gcc on Linux, some version of Clang on OSX, MSVC on Windows, and gcc on MinGW. This commit switches Linux, OSX, and Windows to all use Clang 6.0.0 to build LLVM (aka the C/C++ compiler as part of the bootstrap). This looks to generate faster code according to #49879 which translates to a faster rustc (as LLVM internally is faster) The major changes here were to the containers that build Linux releases, basically adding a new step that uses the previous gcc 4.8 compiler to compile the next Clang 6.0.0 compiler. Otherwise the OSX and Windows scripts have been updated to download precompiled versions of Clang 6 and configure the build to use them. Note that `cc` was updated here to fix using `clang-cl` with `cc-rs` on MSVC, as well as an update to `sccache` on Windows which was needed to correctly work with `clang-cl`. Finally the MinGW compiler is entirely left out here intentionally as it's currently thought that Clang can't generate C++ code for MinGW and we need to use gcc, but this should be verified eventually.
2018-04-24 10:34:14 -05:00
- if NOT defined MINGW_URL set RUST_CONFIGURE_ARGS=%RUST_CONFIGURE_ARGS% --set llvm.clang-cl=C:\clang-rust\bin\clang-cl.exe
appveyor: Upgrade to gcc for mingw 6.3.0 This commit sort of brings back #40777 by upgrading back to 6.3.0. While investigating #40546 it was discovered that 6.3.0 appears to not spurious fail in the same way that 6.2.0 does (which we're currently using). The workaround for #40184 contained in #40777 did not work so this commit also contains a different workaround for the gdb issue. We will not download the 6.2.0 version of gdb and use that instead of the default version that comes with 6.3.0. I'm going to optimistically say... Closes #40546
2017-04-20 10:35:03 -05:00
# Here we do a pretty heinous thing which is to mangle the MinGW installation
# we just had above. Currently, as of this writing, we're using MinGW-w64
# builds of gcc, and that's currently at 6.3.0. We use 6.3.0 as it appears to
# be the first version which contains a fix for #40546, builds randomly
# failing during LLVM due to ar.exe/ranlib.exe failures.
#
# Unfortunately, though, 6.3.0 *also* is the first version of MinGW-w64 builds
# to contain a regression in gdb (#40184). As a result if we were to use the
# gdb provided (7.11.1) then we would fail all debuginfo tests.
#
# In order to fix spurious failures (pretty high priority) we use 6.3.0. To
# avoid disabling gdb tests we download an *old* version of gdb, specifically
# that found inside the 6.2.0 distribution. We then overwrite the 6.3.0 gdb
# with the 6.2.0 gdb to get tests passing.
#
# Note that we don't literally overwrite the gdb.exe binary because it appears
# to just use gdborig.exe, so that's the binary we deal with instead.
- if defined MINGW_URL appveyor-retry appveyor DownloadFile %MINGW_URL%/2017-04-20-%MSYS_BITS%bit-gdborig.exe
- if defined MINGW_URL mv 2017-04-20-%MSYS_BITS%bit-gdborig.exe %MINGW_DIR%\bin\gdborig.exe
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 11:43:26 -05:00
# Otherwise pull in the MinGW installed on appveyor
- if NOT defined MINGW_URL set PATH=C:\msys64\mingw%MSYS_BITS%\bin;C:\msys64\usr\bin;%PATH%
appveyor: Move MSVC dist builds to their own builder In the long run we want to separate out the dist builders from the test builders. This provides us leeway to expand the dist builders with more tools (e.g. Cargo and the RLS) without impacting cycle times. Currently the Travis dist builders double-up the platforms they provide builds for, so I figured we could try that out for MSVC as well. This commit adds a new AppVeyor builder which runs a dist for all the MSVC targets: * x86_64-pc-windows-msvc * i686-pc-windows-msvc * i586-pc-windows-msvc If this takes too long and/or times out we'll need to split this up. In any case we're going to need more capacity from AppVeyor no matter what becaue the two pc-windows-gnu targets can't cross compile so we need at least 2 more builders no matter what.
2017-02-15 11:36:52 -06:00
# Prefer the "native" Python as LLVM has trouble building with MSYS sometimes
- copy C:\Python27\python.exe C:\Python27\python2.7.exe
- set PATH=C:\Python27;%PATH%
rustbuild: Add sccache support This commit adds support for sccache, a ccache-like compiler which works on MSVC and stores results into an S3 bucket. This also switches over all Travis and AppVeyor automation to using sccache to ensure a shared and unified cache over time which can be shared across builders. The support for sccache manifests as a new `--enable-sccache` option which instructs us to configure LLVM differently to use a 'sccache' binary instead of a 'ccache' binary. All docker images for Travis builds are updated to download Mozilla's tooltool builds of sccache onto various containers and systems. Additionally a new `rust-lang-ci-sccache` bucket is configured to hold all of our ccache goodies.
2016-12-12 13:36:52 -06:00
# Download and install sccache
Update all s3 URLs used on CI with subdomains Ensure that they're all forwards-compatible with AWS updates happening next year by ensuring the bucket name shows up in the domain name. Closes #61168
2019-05-28 15:20:43 -05:00
- appveyor-retry appveyor DownloadFile https://rust-lang-ci2.s3.amazonaws.com/rust-ci-mirror/2018-04-26-sccache-x86_64-pc-windows-msvc
ci: Compile LLVM with Clang 6.0.0 Currently on CI we predominately compile LLVM with the default system compiler which means gcc on Linux, some version of Clang on OSX, MSVC on Windows, and gcc on MinGW. This commit switches Linux, OSX, and Windows to all use Clang 6.0.0 to build LLVM (aka the C/C++ compiler as part of the bootstrap). This looks to generate faster code according to #49879 which translates to a faster rustc (as LLVM internally is faster) The major changes here were to the containers that build Linux releases, basically adding a new step that uses the previous gcc 4.8 compiler to compile the next Clang 6.0.0 compiler. Otherwise the OSX and Windows scripts have been updated to download precompiled versions of Clang 6 and configure the build to use them. Note that `cc` was updated here to fix using `clang-cl` with `cc-rs` on MSVC, as well as an update to `sccache` on Windows which was needed to correctly work with `clang-cl`. Finally the MinGW compiler is entirely left out here intentionally as it's currently thought that Clang can't generate C++ code for MinGW and we need to use gcc, but this should be verified eventually.
2018-04-24 10:34:14 -05:00
- mv 2018-04-26-sccache-x86_64-pc-windows-msvc sccache.exe
Update sccache binaries on CI Currently CI builds can fail spuriously during the LLVM build (#39003). I believe this is due to sccache, and I believe that in turn was due to the fact that the sccache server used to just be a raw mio server. Historically raw mio servers are quite complicated to get right, but this is why we built Tokio! The sccache server has been migrated to Tokio which I suspect would fix any latent issues. I have no confirmation of this (never been able to reproduce the deadlock locally), but my hunch is that updating sccache to the master branch will fix the timeouts during the LLVM build. The binaries previously came from Gecko's infrastructure, but I've built new ones by hand for Win/Mac/Linux and uploaded them to our CI bucket.
2017-02-24 15:16:54 -06:00
- set PATH=%PATH%;%CD%
rustbuild: Add sccache support This commit adds support for sccache, a ccache-like compiler which works on MSVC and stores results into an S3 bucket. This also switches over all Travis and AppVeyor automation to using sccache to ensure a shared and unified cache over time which can be shared across builders. The support for sccache manifests as a new `--enable-sccache` option which instructs us to configure LLVM differently to use a 'sccache' binary instead of a 'ccache' binary. All docker images for Travis builds are updated to download Mozilla's tooltool builds of sccache onto various containers and systems. Additionally a new `rust-lang-ci-sccache` bucket is configured to hold all of our ccache goodies.
2016-12-12 13:36:52 -06:00
appveyor: Use Ninja to build LLVM on MinGW I have a suspicion that MinGW's make is the cause of #40546 rather than anything else, but that's purely a suspicion without any facts to back it up. In any case we'll eventually be moving the MSVC build over to Ninja in order to leverage sccache regardless, so this commit simply jumpstarts that process by downloading Ninja for use by MinGW anyway. I'm not sure if this closes #40546 for real, but this is my current best shot at closing it out, so... Closes #40546
2017-03-15 09:35:35 -05:00
# Download and install ninja
#
# Note that this is originally from the github releases patch of Ninja
Update all s3 URLs used on CI with subdomains Ensure that they're all forwards-compatible with AWS updates happening next year by ensuring the bucket name shows up in the domain name. Closes #61168
2019-05-28 15:20:43 -05:00
- appveyor-retry appveyor DownloadFile https://rust-lang-ci2.s3.amazonaws.com/rust-ci-mirror/2017-03-15-ninja-win.zip
appveyor: Use Ninja to build LLVM on MinGW I have a suspicion that MinGW's make is the cause of #40546 rather than anything else, but that's purely a suspicion without any facts to back it up. In any case we'll eventually be moving the MSVC build over to Ninja in order to leverage sccache regardless, so this commit simply jumpstarts that process by downloading Ninja for use by MinGW anyway. I'm not sure if this closes #40546 for real, but this is my current best shot at closing it out, so... Closes #40546
2017-03-15 09:35:35 -05:00
- 7z x 2017-03-15-ninja-win.zip
appveyor: Use Ninja/sccache on MSVC Now that the final bug fixes have been merged into sccache we can start leveraging sccache on the MSVC builders on AppVeyor instead of relying on the ad-hoc caching strategy of trigger files and whatnot.
2017-02-25 11:53:46 -06:00
- set RUST_CONFIGURE_ARGS=%RUST_CONFIGURE_ARGS% --enable-ninja
appveyor: Use Ninja to build LLVM on MinGW I have a suspicion that MinGW's make is the cause of #40546 rather than anything else, but that's purely a suspicion without any facts to back it up. In any case we'll eventually be moving the MSVC build over to Ninja in order to leverage sccache regardless, so this commit simply jumpstarts that process by downloading Ninja for use by MinGW anyway. I'm not sure if this closes #40546 for real, but this is my current best shot at closing it out, so... Closes #40546
2017-03-15 09:35:35 -05:00
# - set PATH=%PATH%;%CD% -- this already happens above for sccache
rustbuild: Start building --enable-extended This commit adds a new flag to the configure script, `--enable-extended`, which is intended for specifying a desire to compile the full suite of Rust tools such as Cargo, the RLS, etc. This is also an indication that the build system should create combined installers such as the pkg/exe/msi artifacts. Currently the `--enable-extended` flag just indicates that combined installers should be built, and Cargo is itself not compiled just yet but rather only downloaded from its location. The intention here is to quickly get to feature parity with the current release process and then we can start improving it afterwards. All new files in this PR inside `src/etc/installer` are copied from the rust-packaging repository.
2017-01-20 19:03:06 -06:00
# Install InnoSetup to get `iscc` used to produce installers
Update all s3 URLs used on CI with subdomains Ensure that they're all forwards-compatible with AWS updates happening next year by ensuring the bucket name shows up in the domain name. Closes #61168
2019-05-28 15:20:43 -05:00
- appveyor-retry appveyor DownloadFile https://rust-lang-ci2.s3.amazonaws.com/rust-ci-mirror/2017-08-22-is.exe
appveyor: Use InnoSetup from our mirror Chocolatey has been pretty flaky, so let's not rely on it. Closes #43985
2017-08-22 21:42:28 -05:00
- 2017-08-22-is.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /SP-
rustbuild: Start building --enable-extended This commit adds a new flag to the configure script, `--enable-extended`, which is intended for specifying a desire to compile the full suite of Rust tools such as Cargo, the RLS, etc. This is also an indication that the build system should create combined installers such as the pkg/exe/msi artifacts. Currently the `--enable-extended` flag just indicates that combined installers should be built, and Cargo is itself not compiled just yet but rather only downloaded from its location. The intention here is to quickly get to feature parity with the current release process and then we can start improving it afterwards. All new files in this PR inside `src/etc/installer` are copied from the rust-packaging repository.
2017-01-20 19:03:06 -06:00
- set PATH="C:\Program Files (x86)\Inno Setup 5";%PATH%
appveyor: Attempt to debug flaky test runs This commit is an attempt to debug #38620 since we're unable to reproduce it locally. It follows the [advice] of those with AppVeyor to use the `handle.exe` tool to try to debug what processes have a handle to the file open. This won't be guaranteed to actually help us, but hopefully it'll diagnose something at some point? [advice]: http://help.appveyor.com/discussions/questions/2898
2016-12-29 17:58:57 -06:00
# Help debug some handle issues on AppVeyor
Update all s3 URLs used on CI with subdomains Ensure that they're all forwards-compatible with AWS updates happening next year by ensuring the bucket name shows up in the domain name. Closes #61168
2019-05-28 15:20:43 -05:00
- appveyor-retry appveyor DownloadFile https://rust-lang-ci2.s3.amazonaws.com/rust-ci-mirror/2017-05-15-Handle.zip
appveyor: Attempt to debug flaky test runs This commit is an attempt to debug #38620 since we're unable to reproduce it locally. It follows the [advice] of those with AppVeyor to use the `handle.exe` tool to try to debug what processes have a handle to the file open. This won't be guaranteed to actually help us, but hopefully it'll diagnose something at some point? [advice]: http://help.appveyor.com/discussions/questions/2898
2016-12-29 17:58:57 -06:00
- mkdir handle
appveyor: Wrap handle.exe download in a retry Should help deal with spurious download failures.
2017-05-14 14:41:42 -05:00
- 7z x -ohandle 2017-05-15-Handle.zip
appveyor: Attempt to debug flaky test runs This commit is an attempt to debug #38620 since we're unable to reproduce it locally. It follows the [advice] of those with AppVeyor to use the `handle.exe` tool to try to debug what processes have a handle to the file open. This won't be guaranteed to actually help us, but hopefully it'll diagnose something at some point? [advice]: http://help.appveyor.com/discussions/questions/2898
2016-12-29 17:58:57 -06:00
- set PATH=%PATH%;%CD%\handle
- handle.exe -accepteula -help
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 11:43:26 -05:00
test_script:
Enable appveyor cache, add more paranoia
2017-04-04 16:51:16 -05:00
- if not exist C:\cache\rustsrc\NUL mkdir C:\cache\rustsrc
- sh src/ci/init_repo.sh . /c/cache/rustsrc
mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md`, `CONTRIBUTING.md`, `src/bootstrap/README.md`, and throughout the source code of rustbuild itself. Closes #37858
2016-11-16 14:31:19 -06:00
- set SRC=.
- set NO_CCACHE=1
Revert "Rollup merge of #58162 - pietroalbini:track-259, r=alexcrichton" This reverts commit 4c243e2c3d8f02cdcd22fe68acf6a0b3edca2078, reversing changes made to 64f0032a3739b18ae45387744340d9c7ce48b145.
2019-02-06 08:16:50 -06:00
- sh src/ci/run.sh
Add AppVeyor configuration to the repo We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds an `appveyor.yml` configuration file which is ready to run builds on the auto branch. This is also accompanied with a few minor fixes to the build system and such to accomodate AppVeyor. The intention is that we're not switching over to AppVeyor entirely just yet, but rather we'll watch the builds for a week or so. If everything checks out then we'll start gating on AppVeyor instead of Buildbot!
2016-10-07 11:43:26 -05:00
branches:
only:
- auto
Reference in New Issue Copy Permalink