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