There are two sorts of auto-generated files
cabal at stefan-klinger.de
Mon Jul 19 18:26:23 UTC 2021
thanks for getting back to me so quickly.
Mikolaj Konarski (2021-Jul-19, excerpt):
> 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
...so the plan would be to raise an issue on
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
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!
Stefan Klinger, Ph.D. -- computer scientist o/X
I prefer receiving plain text messages, not exceeding 32kB.
More information about the cabal-devel