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 <[email protected]> > 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 > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
