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

Carter Schonwald carter.schonwald at gmail.com
Thu Jan 9 23:43:17 PST 2014

If the in rust approach is chosen, I warmly recommend checking out some of
the design ideas in Shake.  Shake has a pretty nice design that allows for
 dynamic build deps (in make systems the way around that is to use make to
make your make files), and a few other neat ideas, including but not
limited to playing nice with ninja files (which I believe cmake can
generate too).


On Friday, January 10, 2014, George Makrydakis wrote:

> Hello,
> Having a build system entirely dependent of Rust alone, would make the
> entire experience in deploying the language extremely cohere. The only
> counter - argument is indeed that it would require some work to get this to
> fruition. I would like to know if this has any chance of getting priority
> soon enough.
> G.
> Corey Richardson <corey at octayn.net> wrote:
> >Hey all,
> >
> >The build system has grown a fair bit of complexity, and is getting
> >hard to understand. I've been thinking about what could replace it
> >moving forward. Most of the complexity stems from having to self-host
> >(ie, staging) and cross compilation (which target are we compiling
> >for, and with which host?)
> [...]
> >3. Write a build system in Rust.
> >
> >This would take care of everything for us, using ourselves. We'd have
> >a small script fetch the snapshot and build the build system, and then
> >hand off the rest of the build to it. This has the advantage of one
> >less build-time dependency, but the disadvantage that it's going to be
> >a lot of work. This could also potentially output tup, ninja[3], or
> >another form of build script after taking configuration options and
> >so-forth. It could also integrate with librustc for smart handling of
> >comments-or-test-only changes, an issue near to my heart[4]. This
> >build system could potentially be rustpkg, but as I understand it the
> >current idea is to *remove* rustpkg's ability as a build system and
> >keep it as a package manager. (At least, that is what I've understood
> >of recent discussion; this could be wrong.)
> [...]
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140110/795a2095/attachment.html>

More information about the Rust-dev mailing list