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

Jan Niklas Hasse jhasse at gmail.com
Fri Jan 10 00:54:21 PST 2014

Have you heart about waf? http://code.google.com/p/waf/

It only depends on Python so this would not result in another dependency.
The python script (< 200 kB) can be included in the repository.

I am all for using rustpkg though. And I'm strongly against cmake, because
I don't know its language and don't like a build system which doesn't use
an already existing one (like scons is using Python). Also cmake still
depends on make (or even worse Visual Studio / Xcode).

2014/1/10 Corey Richardson <corey at octayn.net>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140110/ce7c572c/attachment.html>

More information about the Rust-dev mailing list