[rust-dev] RFC: Future of the Build System

comex comexk at gmail.com
Tue Jan 14 01:29:17 PST 2014

On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
<irrequietus at gmail.com> wrote:
> Again, note that this rather long thread is about discussing in the end what
> the official stance should be. There is no valid reason other than lack of
> manpower and / or language immaturity for having to depend on ruby, python,
> autotools, cmake or whatever else in order to build rust software.

There is no reason every language should have its own build system
written from scratch (or package manager, for that matter); the goals
of each language community are really mostly identical, and the
existing duplication leads to software that's worse than it has to be
(e.g. inconsistent support for signed packages), a waste of time
relearning the same concepts for multiple build systems / package
managers, and difficulty for packages that include code written in
multiple languages.  Meanwhile, satisfying the dependencies you
mentioned is trivial on most systems.

However, I'd say there is a stunning lack of existing build systems
that actually combine a clean design, flexibility, portability, and
performance.  autotools fails badly on design, performance, and
(ironically) portability; cmake fails on design (seriously, try to
read any cmake script) and flexibility (a lot of stuff is hard coded
in C++ and hard to change); most of the alternatives I know about are
at least slow, and often poorly maintained, insufficiently general, et
cetera.  The only build tool I really like is ninja, and it's
designed to be used with input generated from a separate tool rather
than alone.  So I'd personally like to see a new build system regardless.

More information about the Rust-dev mailing list