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

Gaetan gaetan at xeberon.net
Mon Jan 13 05:46:20 PST 2014


what about using a well known build system as a transition to a custom,
rust-written build tool? If this is not planned in rust roadmap, I can't
see how this will work.

For me it's the same old dilemna: write my tool or use an existing one?
Same for doc... should we use sphinx or write a customized tool?

-----
Gaetan



2014/1/11 George Makrydakis <irrequietus at gmail.com>

> There is little reason to believe that having a build system in Rust would
> make It harder for people to package.
>
> I do understand the predependecy argument, but the Rust compiler itself in
> order to compile has predependencies anyway, as does any similar project.
> Therefore the decisional weight of choosing a non - rust based solution
> over a rust one because Debian packagers have problems packaging a compiler
> is not adequately justified.
>
> Using a well known build system as a means to appeal to programmers is
> seemingly an advantage, but it does not exonerate them from having to be
> competent in Rust before they write useful programs. And that has a
> learning curve superior to that of a build system.
>
> As for boost's jam I have nothing to say other than boost having its own
> build system makes it easy for boost first; this does not mean that their
> needs are those of everybody else and boost is a library, not a programming
> language itself. So, again, a decision based on picking a popular solution
> on the basis of such a comparison, has flawed background.
>
> Lastly, imagine the irony of Rust proposing to use python, c, c++ based
> build tools for simple packages. That would make packagers more frustrated
> because of a wider set of dependecies. While end users would have to also
> deal with a known system, its eventual inadequacies could not be met
> directly by Rust devs unless they start amending that system in order to
> deal with them. Therefore, maintenance overhead is inescapable either way,
> with the pessimization of relying in another nom - Rust project in order to
> make it worth your while to enjoy programming in Rust.
>
> The only valid argument against having a build system proposed as the
> official, defacto, cross - platform way of building rust packages written
> in rust is its development and maintenance overhead for the rust core team
> itself.
>
> That problem is easily circumvented by not proposing one right now and
> letting it to the end developer decide. If however an official build system
> is to be proposed, Rust developers merit having it done on their own
> platform, thus proving rust's worth. It is 2014 after all.
>
> G.
>
>
>
> Lee Braiden <leebraid at gmail.com> wrote:
> >On 10/01/14 08:16, Gaetan wrote:
> >>
> >> 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.
> >>
> >
> >I'd agree with that on both counts: the principle of using something
> >standard, and the two recommendations.
> >
> >CMake would probably get my vote, because it's not so much a build
> >tool,
> >as a meta tool for whichever system you prefer, so it would fit in well
> >
> >with various platform-specific IDEs, unusual platforms (android,
> >embedded, ...), etc.  That said, scons is also a strong contender, and
> >which of the two is more open to integrating patches and working with
> >new languages is very much worth considering.
> >
> >I think Rust will be contributing to the wider community by lending its
> >
> >support (and patches) to a common, modern build system, AND it will get
> >
> >something back in terms of users who already know the build system.
> >
> >
> >>     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.
> >>
> >
> >Bear in mind that Debian are having a lot of issues packaging Rust
> >already, because it self-compiles.  If the build tool also had a Rust
> >pre-dependency, that would be a big step backwards.
>
> _______________________________________________
> 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/20140113/933880ac/attachment-0001.html>


More information about the Rust-dev mailing list