There are two sorts of auto-generated files

[Mikolaj Konarski]

> 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