about summary refs log tree commit diff
path: root/src/tools/build-manifest
AgeCommit message (Collapse)AuthorLines
2020-07-16Add RISC-V GNU/Linux to src/tools/build-manifest as a host platformmsizanoen1-0/+1
2020-07-08build dist for x86_64-unknown-illumosJoshua M. Clulow-0/+1
This change creates a new Docker image, "dist-x86_64-illumos", and sets things up to build the full set of "dist" packages for illumos hosts, so that illumos users can use "rustup" to install packages. It also adjusts the manifest builder to expect complete toolchains for this platform.
2020-07-06Add rust-analyzer to the build manifestAleksey Kladov-3/+25
2020-06-25Support configurable deny-warnings for all in-tree crates.Eric Huss-2/+0
2020-06-23Remove unused crate imports in 2018 edition cratesyuqio-1/+0
2020-05-10remove lldb package from bootstrap, config and build-manifestRalf Jung-18/+0
it's not been built since a long time ago
2020-04-14Add illumos triplePatrick Mooney-0/+1
Co-Authored-By: Jason King <jason.brian.king@gmail.com> Co-Authored-By: Joshua M. Clulow <jmc@oxide.computer>
2020-02-28AArch64 bare-metal targets: Build rust-stdAndre Richter-0/+2
This patch enables building of rust-std for the aarch64 bare-metal targets. For the compiler intrinsics, it fetches the AArch64 bare-metal target (aarch64-none-elf) GCC for the A-profile provided by ARM itself from https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads
2020-01-22Rollup merge of #68253 - japaric:bare-metal-cortex-a, r=alexcrichtonTyler Mandry-0/+1
add bare metal ARM Cortex-A targets to rustc -> `rustc --target armv7a-none-eabi` will work also build rust-std (rustup) components for them -> `rustup target add armv7a-none-eabi` will work this completes our bare-metal support of ARMv7 cores on stable Rust (by 1.42 or 1.43) (these target specifications have been tested on a real (no emulation / QEMU) [Cortex-A7 core](https://github.com/iqlusioninc/usbarmory.rs/))
2020-01-21for now, do not build rust-std for the armv7a-none-eabihf targetJorge Aparicio-1/+0
it needs some upstream changes in the build script of the compiler-builtins crate
2020-01-18Add `riscv64gc-unknown-linux-gnu` into target list in build-manifestmsizanoen1-0/+1
Missed in #68037 r? @alexcrichton
2020-01-15add bare metal ARM Cortex-A targets to rustcJorge Aparicio-0/+2
-> `rustc --target armv7-none-eabi` will work also build rust-std (rustup) components for them -> `rustup target add armv7-none-eabi` will work
2019-12-24x.py fmt after previous deignoreMark Rousskov-110/+160
2019-12-20Remove rustc-dev from the default nightly componentsJosh Stone-13/+3
It was already filtered from other branches, but we only kept it in nightly's default to ease the transition. Now that the separation of rust-std/rustc-dev has reached the 1.40 release, it seems like a good time for that transition to end.
2019-11-04more correct error msgRalf Jung-1/+2
2019-11-04avoid using nightly featuresRalf Jung-5/+3
2019-11-03don't fail manifest creation if the toolstate file is missing or mal-formedRalf Jung-5/+9
2019-11-03when Miri tests are not passing, do not add Miri componentRalf Jung-1/+20
2019-10-29Rollup merge of #65843 - xen0n:mips64-musl-targets-with-ci, r=alexcrichtonTyler Mandry-0/+2
Enable dist for MIPS64 musl targets Continuing work in #63165, necessary libc changes are in place and published so here we go!
2019-10-26ci: add support for MIPS64 musl targetsWang Xuerui-0/+2
2019-10-25Merge branch 'master' into rusty-hermit, resolve conflictsStefan Lankes-0/+30
2019-10-15Add rustc-dev to nightly default and complete profilesJosh Stone-0/+15
2019-10-15minimize the rust-std componentJosh Stone-0/+15
This splits out a rustc-dev component with the compiler crates, and keeps the status quo of default installed files on nightly. The default changing to not install compiler libraries by default is left for a future pull request. However, on stable and beta, this does remove the compiler libraries from the set of libraries installed by default, as they are never needed there (per our stability story, they "cannot" be used).
2019-10-12Revert "Auto merge of #64823 - cuviper:min-std, r=Mark-Simulacrum"Mark Rousskov-30/+0
This reverts commit 000d90b11f7be70ffb7812680f7abc6deb52ec88, reversing changes made to 898f36c83cc28d7921a1d7b3605323dc5cfcf533.
2019-10-07Add rustc-dev to nightly default and complete profilesJosh Stone-0/+15
2019-10-07Only install rustc-dev by default on nightlyJosh Stone-1/+9
2019-10-07add rustc-dev to tools/build-manifestJosh Stone-0/+7
2019-10-06redesign of the interface to the unikernel HermitCoreStefan Lankes-0/+2
- the old interface between HermitCore and the Rust Standard Library based on a small C library (newlib) - remove this interface and call directly the unikernel - remove the dependency to the HermitCore linker - use rust-lld as linker
2019-09-23Add `#![deny(warnings)]` to internal toolsAlex Crichton-0/+2
2019-09-17build-manifest: add some commentsRalf Jung-4/+13
2019-09-17Revert "Rollup merge of #64451 - RalfJung:miri-manifest, r=pietroalbini"Pietro Albini-51/+5
This reverts commit 7975973e2b806a7ee8e54b40f9e774528a777e31, reversing changes made to f0320e54c7c2c923e2e05996ac1d74f781115bbc.
2019-09-14build-manifest: when Miri tests are not passing, do not add Miri componentRalf Jung-5/+51
2019-08-20Bump toml dependency.Eric Huss-1/+1
Just removing an old/duplicated dependency from the workspace.
2019-08-06redox: convert to target_family unixJeremy Soller-0/+1
2019-08-02Added support for armv7-unknown-linux-gnueabi and armv7-unknown-linux-musleabi.Adrian Budau-0/+2
Support for the targets in the compiler and std build in the CI.
2019-07-28Remove lint annotations in specific crates that are already enforced by ↵Vadim Petrochenkov-2/+0
rustbuild Remove some random unnecessary lint `allow`s
2019-07-18Add riscv32i-unknown-none-elf targetVadim Kaushan-0/+1
2019-06-12Add an alias for x86_64-sun-solaris target tupleLzu Tao-0/+1
2019-05-10Auto merge of #60585 - sunfishcode:wasm32-wasi, r=alexcrichtonbors-1/+1
Omit the vendor component in the WASI triple This renames wasm32-unknown-wasi to wasm32-wasi, omitting the vendor component. This follows aarch64-linux-android, x86_64-fuchsia, and others in omitting the vendor field, which has the advantage of aligning with the [multiarch tuple](https://wiki.debian.org/Multiarch/Tuples), and of being less noisy. r? @alexcrichton
2019-05-09Omit the vendor component in the WASI tripleDan Gohman-1/+1
This renames wasm32-unknown-wasi to wasm32-wasi, omitting the vendor component. This follows aarch64-linux-android, x86_64-fuchsia, and others in omitting the vendor field, which has the advantage of aligning with the [multiarch tuple](https://wiki.debian.org/Multiarch/Tuples), and of being less noisy.
2019-05-09remove unneeded `extern crate`s from build toolsAndy Russell-1/+0
2019-04-03Add dist builder for Armv8-M Baseline and HFHugues de Valon-0/+2
This commit adds the Armv8-M Baseline and Armv8-M Mainline with FPU targets in the list of targets that get their dist components built. It also update the build-manifest so that this target gets also its dist components uploaded.
2019-03-30Rollup merge of #59544 - cuviper:miri-nightly, r=CentrilMazdak Farrokhzad-1/+7
manifest: only include miri on the nightly channel miri needs to build std with xargo, which doesn't allow stable/beta: <https://github.com/japaric/xargo/pull/204#issuecomment-374888868> Therefore, at this time there's no point in making miri available on any but the nightly channel. If we get a stable way to build `std`, like [RFC 2663], then we can re-evaluate whether to start including miri, perhaps still as `miri-preview`. [RFC 2663]: https://github.com/rust-lang/rfcs/pull/2663
2019-03-29manifest: only include miri on the nightly channelJosh Stone-1/+7
miri needs to build std with xargo, which doesn't allow stable/beta: <https://github.com/japaric/xargo/pull/204#issuecomment-374888868> Therefore, at this time there's no point in making miri available on any but the nightly channel. If we get a stable way to build `std`, like [RFC 2663], then we can re-evaluate whether to start including miri, perhaps still as `miri-preview`. [RFC 2663]: https://github.com/rust-lang/rfcs/pull/2663
2019-03-29Add a new wasm32-unknown-wasi targetAlex Crichton-0/+1
This commit adds a new wasm32-based target distributed through rustup, supported in the standard library, and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules, allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem, networking, threads, etc. Instead it only provides the most basic of integration with the wasi syscalls, enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit, abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target, but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime], but more will surely emerge! In terms of future development of libstd, I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls, but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear, therefore, how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit, but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust, and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library, there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot, for example, provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management, process exit, and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way, if Rust and C are linked into the same WebAssembly binary they should work together, but that requires that the same C standard library is used. We also, however, want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind, there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go, a fully workable wasi binary pops out. This is incompatible with linking in C code, however, which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code, the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag, but the idea is that you're no longer using the provided static C runtime, but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols, but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:
2019-03-22Rename miri component to miri-previewMateusz Mikuła-3/+4
It should fix installation via rustup and indicates it's not stable yet
2019-03-22Auto merge of #58995 - Centril:refactor-build-manifest, r=alexcrichtonbors-204/+197
Refactor tools/build-mainfest I saw some duplication in https://github.com/rust-lang/rust/pull/58990 and got an itch... Will likely need to be rebased when that lands. Hopefully the PR should have zero semantic changes... r? @alexcrichton
2019-03-16Rollup merge of #59212 - mati865:musl_toolchain, r=alexcrichtonkennytm-0/+1
Add x86_64 musl host to the manifest @alexcrichton r? Probably too late for https://github.com/rust-lang/rust/pull/59207
2019-03-16Rollup merge of #58941 - wzssyqa:master, r=alexcrichtonkennytm-0/+8
MIPS: add r6 support MIPS r6 is quite different with the previous version. It use some new target triples: mipsisa32r6-unknown-linux-gnu mipsisa32r6el-unknown-linux-gnu mipsisa64r6-unknown-linux-gnuabi64 mipsisa64r6el-unknown-linux-gnuabi64 This patch has been tested with Debian Port for mips64r6el, and the support of these triples also is included in llvm: https://reviews.llvm.org/rGe58c45a695f39004710b6ce940d489fee800dbd3
2019-03-15Add x86_64 musl host to the manifestMateusz Mikuła-0/+1
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-26 05:04:11 +0000