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

George Makrydakis irrequietus at gmail.com
Sat Jan 11 03:26:23 PST 2014


Indeed. I fully agree with your apt foreshadowing of events.

If it is not feasible to have a rust based tool now, as long as any other tool is not given priviledged status formally speaking, using whatever ready means appropriate is a strategy that scales well within a limited time period.

>From this thread it seems a reasonably acceptable compromise - until a rust tool is given priority; but it is not clear if this is the actual plan. I think that discussing about the merits of other build systems should not be transmuted into an agenda of using them as the blessed defaults.

Specifying this is very important for rust to be a modern, cohere platform - level solution with easy exchange of libraries among users, relying on a common environment that is compatible with the goals of Rust itself. This is why it should be fully controlled by the Rust community, thus written in Rust.

Think about the merit of having such a system in rust, eventually deployed by other projects, unrelated to rust, because it ends up being *that* good.

This is a matter that should be definitively discussed after Rust 1.0, when the language starts being backwards - reliable to a considerable extent.

G.

Michael Neumann <mneumann at ntecs.de> wrote:
>rustc is "just" another regular Rust application. So use the tools that
>
>any other Rust application (will) use ;-)
>
>I think at some point in time there will be a capable build tool
>written 
>in Rust (like there is for all the other languages). Then it would make
>sense to switch using it for the compiler as well.
>
>Michael
>
>Am 11.01.2014 08:56, schrieb George Makrydakis:
>> 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
>
>_______________________________________________
>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/20140111/d5d5c3c4/attachment-0001.html>


More information about the Rust-dev mailing list