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