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

Corey Richardson corey at octayn.net
Thu Jan 9 21:46:43 PST 2014

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

More information about the Rust-dev mailing list