search

danielschemmel / build-info

Collects build-information of your Rust crate
https://crates.io/crates/build-info
24 stars 11 forks source link

Hello from `auditable` crate 👋 #2

Closed Shnatsel closed 4 years ago

Shnatsel commented 4 years ago

I'm working on a somewhat similar crate and wanted to say hi. Perhaps we could learn something from each other, and/or share code since the licenses are compatible. My crate is an implementation of this Cargo RFC to get some experience with it before uplifting it into Cargo, so the scope is somewhat different.

The differences I could spot at a glance are:

  1. build-info records more information than auditable
  2. build-info requires the user to modify their build.rs. auditable only needs to be a dependency to work, but its detection of Cargo.lock location is less reliable than in build-info. This was a conscious trade-off that only makes sense for auditable.
  3. build-info records contents of Cargo.toml instead of Cargo.lock, so the exact versions of the dependencies used in the build are not recorded. Is that intentional?
Shnatsel commented 4 years ago

There's also https://github.com/lukaslueg/built

danielschemmel commented 4 years ago

Hello @Shnatsel,

this crate is intended to record any and all information developers might require when the bug reports come rolling in, especially when distributing source code. ("There is a bug in version 1!" - "What is the exact version number?" - "1.0.4" - "We never released that version." - "Well, I compiled it from git." - "Ok, which commit?" - "$SOMESHA" - "I still cannot reproduce your bug" - "Well, we had to modify the sources a bit...")

  1. My goal is to record anything that could be useful, and let the user of the crate figure out what they want to actually use from that.
  2. build.rs is the only way I know of that ensures that the data is regenerated whenever the source-code is recompiled (this is necessary to detect what exact version of the sources was compiled)
  3. Dependency-tracking is still in its infancies, but I am reasonable sure that build-info tracks the actual versions. Have a look at the output of cargo run --bin dependency-tree to see └──xz2 v0.1.6 [] in the output. This project only uses xz = "0.1" to specify the dependency in Cargo.toml.
Shnatsel commented 4 years ago

build.rs is the only way I know of that ensures that the data is regenerated whenever the source-code is recompiled (this is necessary to detect what exact version of the sources was compiled)

Aw crab, you're right. There goes my clever idea. Thanks for pointing this out!