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

George Makrydakis irrequietus at gmail.com
Mon Jan 13 07:30:22 PST 2014


Several lengthy emails have full argumentation in supporting that as an interim solution given the current status of Rust itself. It is the adoption of a third party tool, not written in rust, as the defacto standard to use with official blessing, that should be discarded for reasons already discussed.

Again, note that this rather long thread is about discussing in the end what the official stance should be. There is no valid reason other than lack of manpower and / or language immaturity for having to depend on ruby, python, autotools, cmake or whatever else in order to build rust software.

Is Rust capable, as a systems language, of having a build system in Rust for Rust, or it should depend on other languages, *officially* for such a thing?

Personal preferences matter up to a point, but no more.


Gaetan <gaetan at xeberon.net> wrote:
>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/46f3b005/attachment.html>


More information about the Rust-dev mailing list