Rust 1.8 takes steps to replace the Make build system

Serdar Yegulalp |
April 15, 2016

Shedding Make for a Cargo-based build system that is friendlier to potential contributors will help boost Rust's ecosystem

Mozilla yesterday afternoon released version 1.8 of Rust, a system-level language designed to provide the speed of C and the safety of higher-level languages. The revision cleans up the standard library and adds language features, but most noteworthy, it moves away from the Unix Make tool in favor of Rust's Cargo package manager.

To become self-hosted and less reliant on external tools, Rust must build with its own language. Many new languages undergo this shift as a rite of passage. Google's Go language, starting with version 1.5, had a compiler and runtime written entirely in Go (with a smidgen of assembler) and was able to shed its C-based build tooling.

The developers' list of reasons for switching from Make to Cargo is a litany of difficulties that crop up when developing any major software, not only a language. For one, they said the current Make-based build system is "impenetrable to all but a few people on this planet," meaning it's difficult for the vast majority of prospective Rust contributors -- a big negative for a language that's prided itself on having a friendly and welcoming atmosphere.

Another problem with Rust's Make-based build system is portability. Building for Windows environments using the MSVC toolchain requires "crazy and weird hacks to work around all sorts of versions of software everywhere, especially when it comes to the configure script and makefiles," Rust developers said. With information about portability moving into crates, the community can more easily leverage the information in the build process.

Also, changing to a Crate build system allows Rust's standard library and compiler to benefit from the 4,600-plus existing Cargo packages.

Rust's issues with building via MSVC aren't isolated. Many newly developed languages -- those that aren't sponsored by Microsoft, anyway -- tend to give Windows users short shrift because of the peculiarities of that platform's build process. Rust has worked through similar issues already; for instance, version 1.8now allows 32-bit Windows MSVC builds to perform proper unwinding for handling errors. The long-term shift toward a self-hosted build process is meant to help avoid such potholes.