I think this is the best move right now. We should try and port the most notable Rust projects like Servo (or even Rust itself if someone is that ballsy) to Rustpkg and see how it works out.
On Thu, Feb 21, 2013 at 3:25 AM, Benjamin Striegel <[email protected]>wrote: > I think it would be useful to address all of these points with real > examples and see if we can come up with solutions if Rust is currently > falling short. For instance, in the imperative API, running external > programs is *really* hideously ugly right now (by the end of the day I'll > have submitted a pull request to try and address this). > > > On Wed, Feb 20, 2013 at 8:50 AM, Dean Thompson <[email protected] > > wrote: > >> After using sbt (http://www.scala-sbt.org/) extensively, I have become >> quite uncomfortable with compiled languages that use themselves as their >> build automation language. Sbt is the primary Scala build tool, and uses >> Scala as its build automation language. >> >> The appeal is obvious: Rust is the only language we know for certain is >> available on the machine, and also the only language we know that the >> programmer knows and can presume they like. >> >> However, in my experience with sbt, I have seen many problems with this >> model. (Perhaps others on this list know recursive-build environments >> where these problems have been avoided?) >> >> ** How is the build automation code compiled? >> >> If (as envisioned here so far) it can only be compiled using the default >> compilation rules, that is a huge simplification. However, over time it >> likely will not suffice. Builds can become legitimately complex (such as >> source generation tools, multiple languages, and preprocessed resources). >> Over time, many off-the-shelf build automation components are created (for >> example, here's a list of Ant tasks: >> https://ant.apache.org/manual/tasksoverview.html). >> >> If a project's build automation is too complex to be compiled with the >> default compilation rules, then what? Sbt's approach (perhaps inevitable) >> is to allow a subproject containing the build automation for compiling the >> build automation. And, of course, you might need a sub-subproject for >> compiling that. As the sbt documentation puts it, "the turtles go all the >> way down" >> (http://www.scala-sbt.org/release/docs/Getting-Started/Full-Def.html). In >> my experience with sbt, even having the initial build-automation >> subproject becomes a brain-twister when problems occur. >> >> ** How are errors in the build automation reported and diagnosed? >> >> One characteristic I have often seen with sbt is that, when you make a >> mistake coding your build automation, the build system can't function well >> enough to give you good diagnostics. For example, sbt often can't display >> a dependency tree until you straighten out your dependencies. >> >> ** What is the interactive experience? >> >> It is extremely useful in a build system to be able to poke around by hand >> -- manually executing tasks and inspecting state. Sbt has a very >> well-developed, and in many ways quite nice, interactive environment for >> this. However, that environment has an uneasy relationship with the Scala >> code that is the true underlying build automation, since it isn't natural >> to type Scala code interactively. >> >> ** Is the target language really a natural build automation language? >> >> In Scala's case, having spent much time with sbt, I don't feel Scala is >> the language I would choose for writing build automation. Although I am a >> fan of statically typed languages for many purposes, they don't seem to >> come into their own in short scripts that are centered around manipulating >> text and the filesystem. >> >> * Alternative suggestion >> >> Here's what I said was appealing about using Rust as its own build >> automation language: "Rust is the only language we know for certain is >> available on the machine, and also the only language we know that the >> programmer knows and can presume they like." How close can we come to >> these benefits without using Rust as its own build automation language? >> >> We could address the first issue, "Rust is the only language we know for >> certain is available on the machine", either by choosing a language with a >> compact enough interpreter for us to embed in the Rust tooling, or at >> least by choosing a language that is almost universally available. >> >> We could mitigate the second issue, "the only language we know that the >> programmer knows and can presume they like", by trying to pick a language >> that is generally popular among frustrated C++ programmers, and at least >> that is easy to learn. >> >> At any rate, we would want to pick a language that is very convenient and >> comfortable for manipulating the filesystem. Also, we would like one that >> is natural to use interactively. >> >> My suggestion: Python. >> >> Dean >> >> >> On 2/19/13 5:05 PM, "Graydon Hoare" <[email protected]> wrote: >> >> >Hi, >> > >> >We've recently replaced the cargo package manager with a new (very >> >young) tool called rustpkg; in the process it's (temporarily) broken >> >most of the packages installable through cargo, but we'll be fixing this >> >up before the next release. >> > >> >The main new feature of rustpkg is that it permits writing custom build >> >logic (and custom build tasks) in rust itself, as an escape hatch: if >> >there's a file called pkg.rs in a package repository it is compiled, >> >linked against rustpkg itself and run for various tasks. >> > >> >That's a nice feature and all, but we don't want to force (or even >> >_suggest_) use of the escape hatch by default. We'd like rustpkg to do >> >most things by inferring-sensible-defaults when looking at a repository. >> >In particular, building all the most obvious / findable binary and >> >library crates contained therein, based on simple rules. Preferably >> >rules that don't require parsing all the files in the repo and sorting >> >them into a module-graph just to figure out the targets. There might be >> >a lot of files (cf. src/test/run-pass/*.rs) >> > >> >The simplest rule I've come up with is based on a convention for chosen >> >filenames and their immediately-containing dir names. Specifically the >> >names "lib.rs" for libraries and "bin.rs" for binaries: >> > >> > foo/lib.rs ==> build libfoo-<hash>.so / .dll, a library >> > foo/bin.rs ==> build foo / foo.exe, an executable >> > >> >This is a convention that'll require a certain amount of reorganization >> >to existing code, but it permits multi-library / multi-binary packages >> >in a single source repo, which is an important use-case. Lots of time >> >people want >1 crate in the same git tree. Moreover it makes for a >> >pretty simple naming heuristic that can be derived directly from >> >URL-path-fragment package identifiers, such that: >> > >> > extern mod foo (id = "github.com/graydon/foo"); >> > >> >will pick up a single-library package, assuming there's a single file >> >lib.rs in that repo, and give it the name libfoo-<hash>.so, because >> >'foo' is the immediate parent-dir of the lib.rs file. Whereas: >> > >> > extern mod foo (id = "github.com/graydon/foo/thing"); >> > >> >will look for a thing/lib.rs dir-and-stem inside the >> >github.com/graydon/foo repo, and build-and-link _that_ into >> >libthing-<hash>.so. >> > >> >This should also permit mapping such identifiers to filesystem paths in >> >GOPATH-like workspaces, permitting local workspaces overlaid on global >> >ones and branching (via your VCS -- it does versions!) inside local >> >workspaces and whatnot. In case it's not clear from the sketch here, >> >it's very similar to what Go does -- I think they did a very tidy job >> >and I'm interested in copying its good parts. It feels like we didn't >> >quite hit the mark with cargo and this is an important thing to get >> right. >> > >> >That said, I'm interested in some feedback before we get too far into >> >it, to make sure we aren't making serious mistakes or missing issues >> >that people feel are unpleasant about URL-centric schemes. >> > >> >Any thoughts? Notes on other failure modes in package managers? Requests >> >for ponies? I'd prefer specificity in response, if you can manage it. We >> >all know package management is "generally miserable", but if you can >> >describe _exactly_ how things go wrong in other systems and what we >> >should be trying to avoid, or aiming for, that'd be good. >> > >> >Thanks, >> > >> >-Graydon >> >_______________________________________________ >> >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 > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
