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

Gaetan gaetan at xeberon.net
Fri Jan 10 02:06:46 PST 2014

See this page that compares scons to other build system:

I still personally recommend CMake. One of the major feature is that it is
NOT a build system, it a script factory that generates system dependant
build file: Makefile for GNU, Visual Studio for Windows, Eclipse
It actually replaces all bash scripts we usually write on large projects to
trigger the builds.


2014/1/10 Jan Niklas Hasse <jhasse at gmail.com>

> 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
> _______________________________________________
> 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/47e31bbd/attachment.html>

More information about the Rust-dev mailing list