Hi,
Hi Stefan,
I, too, ran into the requirement to have a compiled Haskell binary print the Git hash it was derived from. There's a package for that (gitrev), which does not work to my satisfaction.
I can see the problem is with `cabal v2-install` breaking gitrev. https://github.com/acfoltzer/gitrev/issues/23 That's unfortunate, but why not use the normal workflow, that is, `cabal build`, possibly with `cabal list-bin`?
Investigation led me to a wider concept. I now think that Cabal should discern two sorts of generated files:
1. Early generated files, that are not stored in the source repository but have to be present in a source distribution created by `cabal sdist`.
2. Late generated files, that are also not in the source distribution but are created during compilation.
If that was possible, then the git hash problem would reduce to a special case of the first sort. (if it already is, where would I find it documented?)
I've elaborated on this a bit, and provide my current attempt to include a git hash into a binary at
https://github.com/s5k6/versionInfo
which demonstrates the current issues when trying so implement such an approach using current Cabal.
This seems a nice workaround for the bug with `cabal v2-install` and `gitrev`. However, this adds complexity, so somebody would need to implement this and then somebody would need to maintain it, preferably a group of interested users, unless this can be shown to solve/simplify other major things in cabal. Would you organize such an interest group, brainstorm and coordinate with cabal maintainers (this list is fine initially, but a ticket would help in the long term)? I guess some of the users or contributors of `gitrev` may be interested.
It also demonstrates the issue of the current auto-generated `Paths_…` module depending on the `base` package.
Why is this an issue? RIO depends on `base`, too. If the worry is that other modules may be mistake start depending on base, perhaps compile Paths in a separate internal library that depends on `base` while the rest of your package demonstrably doesn't? Kind regards, Mikolaj