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

Patrick Walton pcwalton at mozilla.com
Tue Jan 14 09:25:16 PST 2014


On 1/14/14 1:29 AM, comex wrote:
> 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.

This e-mail sums up my feelings to a T, and it's why I'm conflicted 
about the whole matter.

Patrick



More information about the Rust-dev mailing list