Rust is early in its lifecycle as a language and at a stage where useful applications implemented in it are about to break ground. Deciding on a build system without the multitude of pitfalls that affect curent status quo solutions is detrimental to the language now, not after it has established its own legacy.
Your argument can be generalized into language design. By analogy, we should all stick to what we know, depend on older languages and multitudes of dependencies because they work well. If you consider Rust a systems language, surely you see how bizzare - if not somewhat ludicrous - it will sound for Rust to have an *official* (which this thread is all about) build system that needs language relic X to work. You do conclude however in indeed wanting to see some new build system beyond the usual graph theory rehash. On that, we agree. Rust is capable of doing this just for Rust. comex <[email protected]> wrote: >On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis ><[email protected]> 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.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
