See this page that compares scons to other build system: http://www.scons.org/wiki/SconsVsOtherBuildTools
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 projects,... It actually replaces all bash scripts we usually write on large projects to trigger the builds. ----- Gaetan 2014/1/10 Jan Niklas Hasse <[email protected]> > > 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 > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
