For what concerns the entire discussion so far, I think that ninja would be an excellent suggestion as a starting point in cleaning up the build process for both Rust compiler and the standard library.
Because of such a refactoring, what could follow afterwards (post - 1.0 likely) could undoubtedly have better chances in being even cleaner and more useful for both compiler and standard library building. Under current circumstances, it is an alternative with merit. Gaetan <[email protected]> wrote: >To answer to this RFC, I don't see what will be improved if cmake where >used. The makefile macro may be rewritten in CMakeList.txt stuff, but >this >will still generate makefiles and thus don't solve the compilation >time. > >I'm curious about >ninja<http://martine.github.io/ninja/manual.html#_philosophical_overview>, >it is its promise to provide a simple, clean, super-fast Make. It has >been >made to replace the old Makefiles and even scons files to build google >chrome. > >And moreover, it follows the UNIX principles: do one thing but do it >well. >It's adviced to use a "meta build" sytem like CMake or gyp. Does anyone >has >ever used ninja intensively? >And then, a rust meta build program could be written to replace this >metabuilder (i.e. cmake), without having to rewrite the complete ninja >layer (I suppose there will be some ninja module to write to answer >some >issues). >And see if at the end the ninja build layer can be replaced completely >by a >rust one. > >Arg, as I unroll my idea i see that it is exactly the proposal 3 in the >original email... > >For me, poll will not give the necessary feedback about any system, >merely >personal point of view. Maybe it's a good start. A good "deliverable" >should be to generate some small reports with "presentation, pro, >cons..." >the most applicable to the compilation of the rust compiler and then >vote >can happen. >I've opened a doodle here <http://doodle.com/3ngkb9ms9gt2qrap>. > >----- >Gaetan > > > >2014/1/15 George Makrydakis <[email protected]> > >> As an interim solution, any proven build system will do regardless of >> preference. Given the current status quo of Rust's evolving >condition, the >> choice should weigh on the side compatible with what the core >developers >> use since they build way too often. >> >> Simplify the build process by reducing number of tools required, >going >> towards a single tool if possible. That would make the option of >"rusting" >> an alternative, future solution far easier to adopt if that would >still be >> an option. >> >> Should a poll be made instead of these threads? >> >> >> Lee Braiden <[email protected]> wrote: >>> >>> On 14/01/14 23:43, Corey Richardson wrote: >>> >>>> This thread is deviating from its purpose. The idea isn't to hash >out >>>> >>>> a generic build system for all of Rust, merely for the compiler + >stdlib. >>>> >>> >>> I think it naturally progressed, because some people wanted to >discuss a >>> more generic solution. >>> >>> But fair enough... if the only goal is to build rust, I've very >little >>> >>> preference, except to say: >>> >>> Please choose something cross-platform that's as standard as >possible, >>> and leads to builds as simple as "make" or "configure && make" or >>> something along those lines. >>> >>> At the outside, CMake's "cmake -G 'Unix Makefiles' etc. is tolerable >>> (for me), in the name of supporting IDE users. >>> >>> >> _______________________________________________ >> 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
