I am not in favor of a customized build system. For instance boost library use their jam build system, and i never figured how to use it in my projects.
I push to use standard and well proved build system like cmake or scons, at least for major components. This would give a nice example of how to use it in any projects. Le 10 janv. 2014 08:43, "Carter Schonwald" <[email protected]> a écrit : > If the in rust approach is chosen, I warmly recommend checking out some of > the design ideas in Shake. Shake has a pretty nice design that allows for > dynamic build deps (in make systems the way around that is to use make to > make your make files), and a few other neat ideas, including but not > limited to playing nice with ninja files (which I believe cmake can > generate too). > > http://community.haskell.org/~ndm/shake/ > http://hackage.haskell.org/package/shake > > On Friday, January 10, 2014, George Makrydakis wrote: > >> >> Hello, >> >> Having a build system entirely dependent of Rust alone, would make the >> entire experience in deploying the language extremely cohere. The only >> counter - argument is indeed that it would require some work to get this to >> fruition. I would like to know if this has any chance of getting priority >> soon enough. >> >> G. >> >> Corey Richardson <[email protected]> wrote: >> >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?) >> >> [...] >> >> >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.) >> >> [...] >> _______________________________________________ >> 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
