Skip to content

Concept: There are two sorts of auto-generated files #7488

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
s5k6 opened this issue Jul 21, 2021 · 1 comment
Open

Concept: There are two sorts of auto-generated files #7488

s5k6 opened this issue Jul 21, 2021 · 1 comment

Comments

@s5k6
Copy link

s5k6 commented Jul 21, 2021

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 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:

  1. Early generated files, that are not stored in the source repository but have to be present in a source distribution created by cabal sdist.

  2. 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 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

@Mikolaj
Copy link
Member

Mikolaj commented Jul 21, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants