> 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 _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
