Ok -- makes sense. Having been through the sbt pain of Scala-built-by-Scala, I'll watch as Rust's tooling evolves and try to be alert in mentioning patterns that went badly in sbt.
Hopefully others have positive experiences with Xyz-built-by-Xyz, and can mention patterns that help. Dean On 2/20/13 10:15 AM, "Graydon Hoare" <[email protected]> wrote: >On 20/02/2013 5:50 AM, Dean Thompson wrote: >> 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. > >Hm. Ok, I didn't really want to turn this into a language discussion, >but if it's going that way: I don't especially care if users _like_ it >as a build language. Writing "build logic" code is always an unpleasant >concession. The argument for "use rust" is merely that it's sufficiently >powerful, under our control, and we know we have the tool at hand. >Adding another tool adds another very complex moving part (under some >other party's control) to a delicate process we're trying to standardize >and simplify. > >Keep in mind, this is for escape-hatch-use only. We have a rule in >tooling rustc that "any command-line flag you have to pass to make >something compile should be expressible in-source as an attribute". Most >crates should compile most of the time as "rustc <crateroot>.rs". That's >currently often true and we're aiming to make it more commonly true as >we flesh out the dependency logic. > >I want the same sort of rule to apply here: most packages should build >by inference-rules 99% of the time; pkg.rs is the 'unsafe { ... }' block >of build automation. We'll try to discourage its use however possible >(maybe only offer auto-build service to people who don't use it?) > >> 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. > >I think you're conflating issues. If the "default compilation rules" >involve "potentially resolving extern-mod and syntax-extension >dependencies of pkg.rs itself", then it's no simplification at all. It's >exactly the "turtles all the way down" scenario you describe in sbt. >Which, while undesirable as a general occurrence -- I will probably cry >a bit the first time I see it happen -- is (as far as I can see) the >_simplest_ form of escape-hatch-within-an-escape-hatch possible. Which I >hope to be a 1% sub-case within the 1% we're already discussing. > >The other recursive escape hatch, if you want to go sideways, is: > > run::run_command(["python", "my_pythonic_stack_of_turtles.py"]) > >but good luck diagnosing the virtualenv, pip, easy_install, distribute >and such errors emerging from that, mid-build. Python's versioning and >packaging problems are worse than ours; they have a legacy of >incompatible attempts to fight. We at least have few enough past >experiments that we can clean them all up and pretend we're at a blank >slate. > >IMO there's no real easy way out from an over-complex build aside from >"don't make over-complex builds". We should do everything we can to >discourage byzantine build logic: make things work via less-expressive >but automatic defaults whenever possible, and factor anything we see >cropping up in "custom rules" into default inferrable behavior. We added >pkg.rs only because people are currently writing make-and-sh logic and >git submodule forests, which is worse, and harder to factor. > >(I do agree we should be providing a better repl and shell-library >experience out of the box in rust. I don't think that's an argument to >change languages though. Fixing those problems is far less work.) > >-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
