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

Gaetan gaetan at xeberon.net
Fri Jan 10 00:16:49 PST 2014


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" <carter.schonwald at gmail.com> 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 <corey at octayn.net> 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
>> Rust-dev at mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>
> _______________________________________________
> 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/20140110/983be2ae/attachment.html>


More information about the Rust-dev mailing list