You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I, too, ran into the requirement to have a compiled Haskell binary print the Git hash it was derived from. There's a package for that (gitrev), which is currently broken when using cabal v2-install (which seems to be the cabal install of the future).
And rightly so, cabal v2-install points out the dependency on .git, which should(?) not be there.
Finding a workaround led me to recognize a wider concept. I now think that Cabal should discern two sorts of generated files:
Early generated files, that are not stored in the source repository but have to be present in a source distribution created by cabal sdist.
Late generated files, that are also not in the source distribution but are created during compilation.
If that was possible, then the git hash problem would reduce to a special case of the first sort.
I've elaborated on this part a bit, and provide my current attempt to include a git hash into a binary at
https://github.com/s5k6/versionInfo
This also demonstrates that all direct dependencies on base (which not everybody may like) come from Paths_…, because its creation is out of my control. Generalising the idea of late generated code might encompass the generation of the Paths_… module. Giving control over its generation to the developer would removethat 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.
I do understand that there are others with a much deeper understanding of the build process and the implications of my approach. So here I'm asking whether this idea makes sense at all, and how to organise these two phases (if it makes sense).
Cheers
Stefan
The text was updated successfully, but these errors were encountered:
A note: the workaround (https://github.com/s5k6/versionInfo) uses a custom Setup.hs and, as maintainers of cabal, we'd like to limit the use of custom Setup.hs, even just for our own sanity when diagnosing reported bugs. So, the proposal is not to gratuitously add extra complexity to cabal, but to add it instead of a particular use of custom Setup.hs.
Uh oh!
There was an error while loading. Please reload this page.
Hi,
I, too, ran into the requirement to have a compiled Haskell binary print the Git hash it was derived from. There's a package for that (gitrev), which is currently broken when using
cabal v2-install
(which seems to be thecabal install
of the future).And rightly so,
cabal v2-install
points out the dependency on.git
, which should(?) not be there.Finding a workaround led me to recognize a wider concept. I now think that Cabal should discern two sorts of generated files:
Early generated files, that are not stored in the source repository but have to be present in a source distribution created by
cabal sdist
.Late generated files, that are also not in the source distribution but are created during compilation.
If that was possible, then the git hash problem would reduce to a special case of the first sort.
I've elaborated on this part a bit, and provide my current attempt to include a git hash into a binary at
This also demonstrates that all direct dependencies on
base
(which not everybody may like) come fromPaths_…
, because its creation is out of my control. Generalising the idea of late generated code might encompass the generation of thePaths_…
module. Giving control over its generation to the developer would 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.I do understand that there are others with a much deeper understanding of the build process and the implications of my approach. So here I'm asking whether this idea makes sense at all, and how to organise these two phases (if it makes sense).
Cheers
Stefan
The text was updated successfully, but these errors were encountered: