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

Brian Anderson banderson at mozilla.com
Fri Jan 10 11:13:32 PST 2014


I think we are going to end up doing a total rewrite. Here are my 
current concerns:

* We need to make a big change to the way bootstrapping works in order 
to cross-compile correctly: https://github.com/mozilla/rust/issues/11145
* Adding new crates to the current build system is very error-prone. We 
need all the logic for building them to be encapsulated into something 
simple.
* The build system that Rust uses should be the build system we are 
promoting as the defacto community build system, and as such it also 
needs to integrate with rustpkg.

My personal preference is to create a tool that can eventually integrate 
into rustpkg that generates ninja scripts, and package and distribute 
ninja ourselves (as rust-ninja or something).

On 01/09/2014 09:46 PM, Corey Richardson 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?)
>
> Our build system must:
>
> 1. Work on all the platforms we support
> 2. Be able to track dependencies.
>
> Our ideal build system should:
>
> 1. Require minimal build-time dependencies
> 2. Allow ease of staging and cross compilation
> 3. Be easy to extend as we grow
> 4. Have readable build scripts
> 5. Have advanced configuration ability (NO_REBUILD, NO_BENCH, etc
> should all be retained)
>
> There are a few options:
>
> 1. Rework the current makefiles to be nicer.
>
> I'm not sure if this is feasible. Some stuff certainly could be
> easier, but the inherent problems of make (nested evals + calls, no
> named parameters (what does $(1) mean here, etc), general ugliness)
> make this unlikely to be a worthwhile effort, besides factoring out
> some of the current boilerplate.
>
> 2. Use a different build system.
>
> The major option here seems to be cmake[1], although I've heard
> murmurings of tup[2] and some other obscure things. I'm unsure tup is
> going to be of much help here. With our compilation model,
> fine-grained file-based dependencies are not very useful. However,
> it's awesome bottom-up dependency model could be neat. It's possible
> that we could use it with a combination of:
>
> 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.)
>
> 4. Write a build system in $LANG.
>
> Python seems to be a good choice here, since we already depend on it
> for fetching the snapshot etc. This still has the disadvantage of
> being a lot of work, but would perhaps be easier than writing a build
> system in Rust. We would definitely lose hacker points for doing so.
>
> There are undoubtedly other options as well. Does anyone have good
> ideas or opinions on what we should do? Personally I think that 3 is
> going to be the best option, unless there's some super amazing build
> system I haven't heard of it. Which is totally possible!
>
> [1]: http://www.cmake.org/
> [2]: http://gittup.org/tup/
> [3]: http://martine.github.io/ninja/
> [4]: https://github.com/mozilla/rust/issues/6522
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev



More information about the Rust-dev mailing list