Hello, CMake does have a few things going for it:
- It is a popular choice for C++ projects, including LLVM, WebKit and others, so this would provide familiarity from developers coming from C++ - As mentioned, it is a meta-build system which can generate project files for Xcode, Visual Studio, Ninja and others. This is very useful for cross-platform development - It has a good and sizable ecosystem (full time active maintainers, documentation, user questions on StackOverflow etc.) - It has a large collection of modules to find packages, detect compiler versions etc. Downsides for CMake include: - The built script language is primitive and not a familiar language like Python. It is easy enough to use for writing a build project file but for more complex logic, I've found it easier to write separate commands in Python/Ruby which CMake then invokes. - CMakeLists.txt files are not declarative documents that can be easily parsed by other tools for eg. IDE integration. Having said that, the CMake developers are aware of the benefits of more declarative ways of specifying things and there is a general trend in that direction. - Adds a non-rusty dependency to rust. Regards, Rob. On 10 January 2014 10:06, Gaetan <gae...@xeberon.net> wrote: > 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 <jha...@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 <co...@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@mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
