feat: use git-version instead of git2

[mbrobbel]

An alternative approach for #172. This replaces the git2 dependency with git-version which uses the git binary directly at compile time. This means that:

For dev builds, needs git binary:

• There is a submodule checked out: version file is written to the gen folder.
• There is no submodule checked out: the build fails with a hint to clone the submodule.

For packaged builds (substrait is not included as a git submodule, see Cargo.toml includes), don't need a git binary:

• The version file is in the gen folder: the build script skips the version generation part
• The version file is missing: the build fails - the package is broken

[westonpace]

Thanks for looking into this.

[westonpace]

This is a good idea to mark that the code is generated

[westonpace]

Ah, this doesn't seem to be working quite right. I get an error using the released build (because git_submodule_versions! runs immediately, being a macro, even if version.in exists). I'll investigate.

error: failed to determine .git directory: git rev-parse exited with status 128: fatal: not a git repository (or any of the parent directories): .git
  --> /home/pace/.cargo/registry/src/index.crates.io-6f17d22bba15001f/substrait-0.29.1/build.rs:40:31
   |
40 |           const VERSION: &str = git_version::git_submodule_versions!(
   |  _______________________________^
41 | |             args = ["--tags", "--long", "--dirty=-dirty", "--abbrev=40"],
42 | |             fallback = ""
43 | |         )[0]
   | |_________^
   |
   = note: this error originates in the macro `git_version::git_submodule_versions` (in Nightly builds, run with -Z macro-backtrace for more info)

error: could not compile `substrait` (build script) due to previous error

[mbrobbel]

Ah, this doesn't seem to be working quite right. I get an error using the released build (because git_submodule_versions! runs immediately, being a macro, even if version.in exists). I'll investigate.

error: failed to determine .git directory: git rev-parse exited with status 128: fatal: not a git repository (or any of the parent directories): .git
  --> /home/pace/.cargo/registry/src/index.crates.io-6f17d22bba15001f/substrait-0.29.1/build.rs:40:31
   |
40 |           const VERSION: &str = git_version::git_submodule_versions!(
   |  _______________________________^
41 | |             args = ["--tags", "--long", "--dirty=-dirty", "--abbrev=40"],
42 | |             fallback = ""
43 | |         )[0]
   | |_________^
   |
   = note: this error originates in the macro `git_version::git_submodule_versions` (in Nightly builds, run with -Z macro-backtrace for more info)

error: could not compile `substrait` (build script) due to previous error

Hm, it should use the provided fallback (when the git describe fails), I saw this error while testing, and it went away for me after adding the fallback.

[westonpace]

Ah, it seems git_versions! respects fallback but not git_submodule_verisons!

[westonpace]

Ah, nevermind, git_submodule_verisons! does look at fallback but only for some errors.

[mbrobbel]

I'll try to create a patch for the upstream crate.

[westonpace]

Thanks. I think the problem is that, with this kind of failure, git_submodule_versions doesn't even know how many tuples to return (because it doesn't know how many submodules there are). Maybe you can add a new functions git_submodule_version which requires a submodule name as input, and which always respects fallback.

[mbrobbel]

Thanks. I think the problem is that, with this kind of failure, git_submodule_versions doesn't even know how many tuples to return (because it doesn't know how many submodules there are). Maybe you can add a new functions git_submodule_version which requires a submodule name as input, and which always respects fallback.

Yes, I was considering the same, but then I figured we can probably be pragmatic here: #175.