I also agree on the task force proposal, it's the right way to capitalize on past failure and success.
For me, rust-pkg will not success if it doesn't have a proper centralized repository. That's a debate, the current version explicitely specify the URL where to download stuff. But things changes, developers changes, URL get broken, or a new developer forks a project or continue it on another repository. I have quite a good experience (I think) on dependency management, mostly on C++ (QT/Linux projects and embedded) and now python (that's why I love the simplicity and power of pipy!) so I would be glad to be associated with such task force. For me you have two approach: "enough for major use case", things like pipy that do the job for most use case, and "exhaustive approach" where you end up with complicated but extremely powerful do-it-all tools like maven but that get eventually dropped because it's too complex to use. That is also joining the build system thread, where also rustpkg appeared :) But I push to split them appart: the dependency management tool should trigger a build system and not do everything ----- Gaetan 2014-01-28 Huon Wilson <[email protected]> > On 28/01/14 19:36, György Andrasek wrote: > >> I never quite understood the problem `rustpkg` was meant to solve. For >> building Rust code, `rustc --out-dir build` is good enough. For running >> tests and benchmarks, `rustc` is good enough. For downloading things, I >> still need to feed it a github address, which kinda takes away any value it >> could have over `git clone` or git submodules. >> > > rustpkg (theoretically) manages fetching and building dependencies (with > the appropriate versions), as well as making sure those dependencies can be > found (i.e. what the -L flag does for rustc). > > > >> What I would actually need from a build system, i.e. finding {C,C++,Rust} >> libraries, building {C,C++,Rust} libraries/executables and linking them to >> said {C,C++,Rust} libraries, it doesn't do. It also doesn't bootstrap rustc. >> >> > rustpkg is unfinished and has several bugs, so describing its current > behaviour/usage as if it were its intended behaviour/usage is not correct. > I believe it was designed to handle native (non-Rust) dependencies to some > degree. > > > Huon > > > > [Disclaimer: I've never quite got a rustpkg workflow going. It's probably >> awesome, but completely overshadowed by `rustc`.] >> >> On 01/28/2014 09:02 AM, Tim Chevalier wrote: >> >>> On Mon, Jan 27, 2014 at 10:20 PM, Val Markovic <[email protected]> wrote: >>> >>>> >>>> On Jan 27, 2014 8:53 PM, "Jeremy Ong" <[email protected]> wrote: >>>> >>>>> >>>>> I'm somewhat new to the Rust dev scene. Would anybody care to summarize >>>>> roughly what the deficiencies are in the existing system in the >>>>> interest of >>>>> forward progress? It may help seed the discussion for the next effort >>>>> as >>>>> well. >>>>> >>>> >>>> I'd like to second this request. I haven't used rustpkg myself but I've >>>> read >>>> its reference manual ( >>>> https://github.com/mozilla/rust/blob/master/doc/rustpkg.md) and it >>>> sounds >>>> like a reasonable design. Again, since I haven't used it, I'm sure I'm >>>> missing some obvious flaws. >>>> >>> >>> Thirded. I implemented rustpkg as it's currently known, and did so in >>> the open, detailing what I was thinking about in a series of >>> exhaustively detailed blog posts. Since few people seemed very >>> interested in providing feedback on it as I was developing it (with >>> the exception of Graydon, who also worked on the initial design), I >>> assumed that it was on the right track. I rewrote rustpkg because >>> there was a perception that the initial design of rustpkg was not on >>> the right track, nor was cargo, but obviously simply rewriting the >>> whole system from scratch in the hopes that it would be better didn't >>> work, since people are talking about throwing it out. So, before >>> anybody embarks on a third rewrite in the hopes that *that* will be >>> better, I suggest that a working group form to look at what went wrong >>> in the past 2 or 3 attempts at implementing a build system / package >>> system for Rust, so that those mistakes can be learned from. Perhaps >>> all that needs to be done differently is that someone more central to >>> the community needs to write it, but if that's what it takes, it seems >>> preferable to the wasted time and effort that I imagine will ensue >>> from yet another rewrite for the sake of throwing out code. >>> >>> Cheers, >>> Tim >>> >> _______________________________________________ >> Rust-dev mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/rust-dev >> > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
