It provides for a number of features. Specifically, it allows us to embed commit hashes within release versions where desirable, in the following manner v0.13.0-40b7550d. I have added version.rs to the core and wallet. This file contains local public static declarations of some of the info produced by the vergen so that this data can be obtained by dependencies. Some of this data (other than the git summary) may be useful later on.
One of the vectors I am curious about is that it should be possible to use vergen to create deterministic builds for kaspad by setting a static build date, albeit I did not have time to look into this in detail. This is the reason I have kept the build.rs and the build dependency itself in kaspad (while kaspad internally refers to kaspa-core).
I was thinking that perhaps this would merit the removal of kaspa-core::kaspad_env, but it is being used in p2p for version exchange, so I didn't touch it. Perhaps adding git summary (part of the commit hash) to the user-agent would make sense (but then should be done in another PR as this one is just a quick integration).
I have added vergen (https://crates.io/crates/vergen) to
kaspa-core,kaspadandkaspa-wallet-coreIt provides for a number of features. Specifically, it allows us to embed commit hashes within release versions where desirable, in the following manner
v0.13.0-40b7550d. I have addedversion.rsto the core and wallet. This file contains local public static declarations of some of the info produced by the vergen so that this data can be obtained by dependencies. Some of this data (other than the git summary) may be useful later on.One of the vectors I am curious about is that it should be possible to use vergen to create deterministic builds for
kaspadby setting a static build date, albeit I did not have time to look into this in detail. This is the reason I have kept thebuild.rsand the build dependency itself inkaspad(whilekaspadinternally refers tokaspa-core).I was thinking that perhaps this would merit the removal of
kaspa-core::kaspad_env, but it is being used in p2p for version exchange, so I didn't touch it. Perhaps adding git summary (part of the commit hash) to the user-agent would make sense (but then should be done in another PR as this one is just a quick integration).