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
