[rust-dev] RFC: Future of the Build System

George Makrydakis irrequietus at gmail.com
Wed Jan 15 05:56:14 PST 2014


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 <gaetan at xeberon.net> 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 <irrequietus at gmail.com>
>
>> 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 <leebraid at gmail.com> 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
>> Rust-dev at mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140115/949657ad/attachment-0001.html>


More information about the Rust-dev mailing list