There are two sorts of auto-generated files

[Stefan Klinger]

Hello Mikolaj,

thanks for getting back to me so quickly.

Mikolaj Konarski (2021-Jul-19, excerpt):
> 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`?

Hmmmm, I'm sorry, I don't understand what you refer to.  There might
be a normal workflow that I'm not aware of.  Are you hinting at not
using `cabal install` at all, and just grab he binary?  Would that be
a smart approach?  No judgement here, I honestly don't know, but why
have `cabal install` at all then?  How would that scale to tools that
need installation (maybe for setting up data files)?

> >     https://github.com/s5k6/versionInfo
>
> This seems a nice workaround for the bug with `cabal v2-install` and
> `gitrev`.  However, this adds complexity,

Oh yes, indeed.  The more I think of it, the more natural the
distinction between early and late generated code appears to me.  But
I do understand that there are others with a much deeper understanding
of the build process and the implications of my approach.

> Would you organize such an interest group, brainstorm and coordinate
> with cabal maintainers

That's what I'm trying to do here, get brainstorming from the people
who would know.

> (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.

...so the plan would be to raise an issue on

    https://github.com/haskell/cabal/issues

and then point, e.g., the gitrev maintainers to it?  Yes, I can do
that.  Any requirements against how to set up the ticket?  (after
checking: I think I can only file bug reports.  Is that ok?)

> > 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.

I was just thinking that generalising the idea of late generated code
might encompass the generation of the `Paths_…` module.  Giving
control over its generation to the developer would also remove that
complexity from Cabal.  This could be done via a simple
developer-provided template that is used by Cabal to create the
module.  One could use Template Haskell, but I think even a blunt
text-based approach would do, in less than 100 SLOC.

> 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?

Yeah, that sounds like a very good idea (unfortunately, in my real
project I depend on `base` for other reasons, but I'll give it a try
next time I see the opportunity).  Thanks for the hint!

Cheers
Stefan


--
Stefan Klinger, Ph.D. -- computer scientist              o/X
http://stefan-klinger.de                                 /\/
https://github.com/s5k6                                    \
I prefer receiving plain text messages, not exceeding 32kB.