4 ms·

> build.rs is a fallback though, the main "language […] to describe how to a package a [Rust] project" is Toml and the Cargo.toml file (http://doc.crates.io/man

> build.rs is a fallback though, the main "language […] to describe how to a package a [Rust] project" is Toml and the Cargo.toml file (http://doc.crates.io/manifest.html http://doc.crates.io/manifest.html), build.rs is the escape hatch if the main manifest file does not suffice. I get the feeling that they're making the exact same mistake that Cabal/cabal-install did in the Haskell world[1] -- they just don't have complex-enough builds and/or a big enough ecosystem yet to know it. (In Cabal/cabal-install there's a "Custom" build type where "anything goes". Unfortunately that means that it's basically impossible for any higher-level tooling to have any idea of what's going on in the build... and hence it thus powerless to introspect anything useful. It's a huge pain.) [1] Not that I blame them, it's just such a tempting thing to do rather than completely redesigning the build system to accomodate everything and provide enough introspection/metadata. So it goes, I guess...

vvanders 9y ago
Considering ~60% of the use cases for build.rs is wrapping C/C++ builds I'd love to know exactly how you expose metadata for that ;).
- lomnakkus 9y ago
  That's a fair point, but even mandating "choose one of Ninja/CMake/etc." would be helpful in terms of at least getting a little bit of metadata out. This is obviously non-trivial, and I'm not sure how much metadata is even retrievable from my examples, but it's better than nothing. (Ninja and CMake operate at sort of different levels, but that's OK for this purpose, I think. At least you can ask things like "if X changed, what else would change?" without actually having to run a compiler.) (AFAIUI Cabal:Custom had exactly the same reasoning, btw. "It's too difficult! Let's just give up and allow anything.") It might be a practical reality that this is just unavoidable if you want to achieve success, but at a meta-level I think deserves thinking about whether builds should actually be allowed the full Turing Complete treatment. At least, theoretically: As long as we continue 'allowing' Custom for practical reasons and without serious thought, there can be no progress. (Btw, I'm quite mad which it comes to this type of thing. I spend way too much time thinking about build systems, etc.) EDIT: This problem manifests EVERYWHERE: Docker builds randomly guess wrong about whether inputs have changed, cabal-install gets it wrong, SBT/Zinc doesn't quite track dependencies correctly, etc. etc. and it's infuriating.
steveklabnik 9y ago
I wouldn't say it's "the exact same mistake", but rather, the usual thing that happens with technology: you ship a first version, feel out where the drawbacks are, and iterate. There has been some discussion about making things more declarative, if this is ultimately the right approach, etc. But you have to do something before you can know for sure what the problem space entails. In our case, one of the largest uses of build.rs is to link to things written in C and C++; there's no unified tooling there, so if you wanted to make some sort of DSL to handle this, you'd have to also solve that problem, which is a huge undertaking.
- lomnakkus 9y ago
  Right, "mistake" may have been a bit too harsh, but I regularly work with systems written in multiple languages and the amount of necessary hackery (aka "duct tape") is absolutely crazy. The abysmal quality of all the mainstream build systems is just one of my pet peeves. (Incidentally, mainstream also includes "make". It's horrific, though it did get some basic things right.) I am pretty convinced that "we" (as an industry) already actually know 95% of what the 'problem space' of a build system is, but everybody just wants to greenfield and try to do their own. Why? Because it's more fun! There's no actual real rationale for reinventing everything every few years. I guess it comes about from a lack of attention to history and a lack of attention to the state of the art, e.g. Shake in Haskell-land. Sorry to be so negative. I'm sure that Cargo at least works really well according to the 80-20 rule :).

vvanders 9y ago

Considering ~60% of the use cases for build.rs is wrapping C/C++ builds I'd love to know exactly how you expose metadata for that ;).

lomnakkus 9y ago
That's a fair point, but even mandating "choose one of Ninja/CMake/etc." would be helpful in terms of at least getting a little bit of metadata out. This is obviously non-trivial, and I'm not sure how much metadata is even retrievable from my examples, but it's better than nothing. (Ninja and CMake operate at sort of different levels, but that's OK for this purpose, I think. At least you can ask things like "if X changed, what else would change?" without actually having to run a compiler.) (AFAIUI Cabal:Custom had exactly the same reasoning, btw. "It's too difficult! Let's just give up and allow anything.") It might be a practical reality that this is just unavoidable if you want to achieve success, but at a meta-level I think deserves thinking about whether builds should actually be allowed the full Turing Complete treatment. At least, theoretically: As long as we continue 'allowing' Custom for practical reasons and without serious thought, there can be no progress. (Btw, I'm quite mad which it comes to this type of thing. I spend way too much time thinking about build systems, etc.) EDIT: This problem manifests EVERYWHERE: Docker builds randomly guess wrong about whether inputs have changed, cabal-install gets it wrong, SBT/Zinc doesn't quite track dependencies correctly, etc. etc. and it's infuriating.

steveklabnik 9y ago

I wouldn't say it's "the exact same mistake", but rather, the usual thing that happens with technology: you ship a first version, feel out where the drawbacks are, and iterate. There has been some discussion about making things more declarative, if this is ultimately the right approach, etc. But you have to do something before you can know for sure what the problem space entails. In our case, one of the largest uses of build.rs is to link to things written in C and C++; there's no unified tooling there, so if you wanted to make some sort of DSL to handle this, you'd have to also solve that problem, which is a huge undertaking.

lomnakkus 9y ago
Right, "mistake" may have been a bit too harsh, but I regularly work with systems written in multiple languages and the amount of necessary hackery (aka "duct tape") is absolutely crazy. The abysmal quality of all the mainstream build systems is just one of my pet peeves. (Incidentally, mainstream also includes "make". It's horrific, though it did get some basic things right.) I am pretty convinced that "we" (as an industry) already actually know 95% of what the 'problem space' of a build system is, but everybody just wants to greenfield and try to do their own. Why? Because it's more fun! There's no actual real rationale for reinventing everything every few years. I guess it comes about from a lack of attention to history and a lack of attention to the state of the art, e.g. Shake in Haskell-land. Sorry to be so negative. I'm sure that Cargo at least works really well according to the 80-20 rule :).