Go to file

Alex Crichton fc1b4379eb rollup merge of #19755 : alexcrichton/rust-serialize The primary focus of Rust's stability story at 1.0 is the standard library. All other libraries distributed with the Rust compiler are planned to be #[unstable] and therfore only accessible on the nightly channel of Rust. One of the more widely used libraries today is libserialize, Rust's current solution for encoding and decoding types. The current libserialize library, however, has a number of drawbacks: * The API is not ready to be stabilize as-is and we will likely not have enough resources to stabilize the API for 1.0. * The library is not necessarily the speediest implementations with alternatives being developed out-of-tree (e.g. serde from erickt). * It is not clear how the API of Encodable/Decodable can evolve over time while maintaining backwards compatibility. One of the major pros to the current libserialize, however, is `deriving(Encodable, Decodable)` as short-hands for enabling serializing and deserializing a type. This is unambiguously useful functionality, so we cannot simply deprecate the in-tree libserialize in favor of an external crates.io implementation. For these reasons, this commit starts off a stability story for libserialize by following these steps: 1. The deriving(Encodable, Decodable) modes will be deprecated in favor of a renamed deriving(RustcEncodable, RustcDecodable). 2. The in-tree libserialize will be deprecated in favor of an external rustc-serialize crate shipped on crates.io. The contents of the crate will be the same for now (but they can evolve separately). 3. At 1.0 serialization will be performed through deriving(RustcEncodable, RustcDecodable) and the rustc-serialize crate. The expansions for each deriving mode will change from `::serialize::foo` to `::rustc_serialize::foo`. This story will require that the compiler freezes its implementation of `RustcEncodable` deriving for all of time, but this should be a fairly minimal maintenance burden. Otherwise the crate in crates.io must always maintain the exact definition of its traits, but the implementation of json, for example, can continue to evolve in the semver-sense. The major goal for this stabilization effort is to pave the road for a new official serialization crate which can replace the current one, solving many of its downsides in the process. We are not assuming that this will exist for 1.0, hence the above measures. Some possibilities for replacing libserialize include: * If plugins have a stable API, then any crate can provide a custom `deriving` mode (will require some compiler work). This means that any new serialization crate can provide its own `deriving` with its own backing implementation, entirely obsoleting the current libserialize and fully replacing it. * Erick is exploring the possibility of code generation via preprocessing Rust source files in the near term until plugins are stable. This strategy would provide the same ergonomic benefit that `deriving` does today in theory. So, in summary, the current libserialize crate is being deprecated in favor of the crates.io-based rustc-serialize crate where the `deriving` modes are appropriately renamed. This opens up space for a later implementation of serialization in a more official capacity while allowing alternative implementations to be explored in the meantime. Concretely speaking, this change adds support for the `RustcEncodable` and `RustcDecodable` deriving modes. After a snapshot is made warnings will be turned on for usage of `Encodable` and `Decodable` as well as deprecating the in-tree libserialize crate to encurage users to use rustc-serialize instead.		2014-12-17 11:50:23 -08:00
man
mk	rollup merge of #19753 : brson/rust-installer	2014-12-17 11:50:23 -08:00
src	rollup merge of #19755 : alexcrichton/rust-serialize	2014-12-17 11:50:23 -08:00
.gitattributes
.gitignore
.gitmodules
.mailmap
.travis.yml
AUTHORS.txt
configure
CONTRIBUTING.md
COPYRIGHT
LICENSE-APACHE
LICENSE-MIT
Makefile.in
README.md
RELEASES.md

README.md

The Rust Programming Language

This is a compiler for Rust, including standard libraries, tools and documentation.

Quick Start

Download a binary installer for your platform.
Read the guide.
Enjoy!

Note: Windows users can read the detailed using Rust on Windows notes on the wiki.

Building from Source

Make sure you have installed the dependencies:
- g++ 4.7 or clang++ 3.x
- python 2.6 or later (but not 3.x)
- perl 5.0 or later
- GNU make 3.81 or later
- curl
- git
Download and build Rust:

You can either download a tarball or build directly from the repo.

To build from the tarball do:
```
 $ curl -O https://static.rust-lang.org/dist/rust-nightly.tar.gz
 $ tar -xzf rust-nightly.tar.gz
 $ cd rust-nightly
```
Or to build from the repo do:
```
 $ git clone https://github.com/rust-lang/rust.git
 $ cd rust
```
Now that you have Rust's source code, you can configure and build it:
```
 $ ./configure
 $ make && make install
```
Note: You may need to use sudo make install if you do not normally have permission to modify the destination directory. The install locations can be adjusted by passing a --prefix argument to configure. Various other options are also supported, pass --help for more information on them.

When complete, make install will place several programs into /usr/local/bin: rustc, the Rust compiler, and rustdoc, the API-documentation tool.
Read the guide.
Enjoy!

Building on Windows

To easily build on windows we can use MSYS2:

Grab the latest MSYS2 installer and go through the installer.
Now from the MSYS2 terminal we want to install the mingw64 toolchain and the other tools we need.
```
 $ pacman -S mingw-w64-i686-toolchain
 $ pacman -S base-devel
```
With that now start mingw32_shell.bat from where you installed MSYS2 (i.e. C:\msys).
From there just navigate to where you have Rust's source code, configure and build it:
```
 $ ./configure
 $ make && make install
```

Notes

Since the Rust compiler is written in Rust, it must be built by a precompiled "snapshot" version of itself (made in an earlier state of development). As such, source builds require a connection to the Internet, to fetch snapshots, and an OS that can execute the available snapshot binaries.

Snapshot binaries are currently built and tested on several platforms:

Windows (7, 8, Server 2008 R2), x86 and x86-64 (64-bit support added in Rust 0.12.0)
Linux (2.6.18 or later, various distributions), x86 and x86-64
OSX 10.7 (Lion) or greater, x86 and x86-64

You may find that other platforms work, but these are our officially supported build environments that are most likely to work.

Rust currently needs about 1.5 GiB of RAM to build without swapping; if it hits swap, it will take a very long time to build.

There is a lot more documentation in the wiki.

Getting help and getting involved

The Rust community congregates in a few places:

StackOverflow - Get help here.
/r/rust - General discussion.
discuss.rust-lang.org - For development of the Rust language itself.

License

Rust is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0), with portions covered by various BSD-like licenses.