4 ms·

This is what makes me love Rust/Cargo so much. You can create pre-build orchestration in your build.rs in the same language as you build your project.

deleted 9y ago
[deleted]
pornel 9y ago
Initially I thought they've lost their mind to replace domain-specific scripting languages with Rust, but I've come around to love it. It has enabled Cargo use its own package ecosystem at build time as well, so build scripts can easily reuse other crates instead of reinventing the wheel for each project. It also saved Cargo from needing to be a build system that works with everything and supports everyone (the midlayer mistake[1]) and instead 3rd party build-time crates and *-sys library wrappers provide the flexibility. [1] https://lwn.net/Articles/336262/ https://lwn.net/Articles/336262/
- masklinn 9y ago
  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. Python uses a Python script as the main entry point to the package, and it's commonly problematic as doing all kinds of weird shit so your package builds (on your machines, until you change your configuration) is a smaller step than looking up what the system already provides, and thus the default. It also makes static package in(tro)spection much more difficult.
  - lomnakkus 9y ago
    > 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.
      - 9y ago

deleted 9y ago

[deleted]

pornel 9y ago

Initially I thought they've lost their mind to replace domain-specific scripting languages with Rust, but I've come around to love it. It has enabled Cargo use its own package ecosystem at build time as well, so build scripts can easily reuse other crates instead of reinventing the wheel for each project. It also saved Cargo from needing to be a build system that works with everything and supports everyone (the midlayer mistake[1]) and instead 3rd party build-time crates and *-sys library wrappers provide the flexibility. [1] https://lwn.net/Articles/336262/ https://lwn.net/Articles/336262/

masklinn 9y ago
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. Python uses a Python script as the main entry point to the package, and it's commonly problematic as doing all kinds of weird shit so your package builds (on your machines, until you change your configuration) is a smaller step than looking up what the system already provides, and thus the default. It also makes static package in(tro)spection much more difficult.
- lomnakkus 9y ago
  > 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.
    - 9y ago