Hi,
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?
Depends. I'm not particularly up to date with how people use cabal nowadays, but I think `cabal build` is the default, `cabal run` is for when needing to run something once and `cabal install` mostly for installing build tools that will be used often, but these should often be installed automatically one way or another.
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)?
I'm told data files generally don't work (probably too much variety in directory schemes among OSes and even their versions). So either embed your data or set up a fixed known directory with them via other means.
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.
That's one more reason not to lose the idea but open a ticket. I don't have such a deep understanding at this time. And mailing lists are sadly out of fashion generally.
...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.
Yes, please.
Any requirements against how to set up the ticket? (after checking: I think I can only file bug reports. Is that ok?)
I guess nobody has the time to work on feature requests (or on updating the ticket template). However, your feature request is welcome, given the thought you've already put into it and the potential of gathering enough interested users to analyze and implement some form of it.
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.
Sounds interesting. I'm sure I wouldn't be able to see obvious problems with that, if there were any, but quite possibly there was just never enough bandwidth nor determined enough users. Cheers, Mikolaj