Skip to content
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

Optionally add the revison number to Paths_$pkgid.version #1506

Open
23Skidoo opened this issue Sep 13, 2013 · 3 comments
Open

Optionally add the revison number to Paths_$pkgid.version #1506

23Skidoo opened this issue Sep 13, 2013 · 3 comments

Comments

@23Skidoo
Copy link
Member

It'd be nice if cabal build could automatically add the revision number for the appropriate SCM to the versionTags field of Paths_$pkgid.version. I envision the following usage scenario:

$ cabal configure --revision-number # or --build-id, or whatever
$ cabal run -- --version
1.0-0a4f3c6g
$ cabal configure
$ cabal run -- --version
1.0

For extracting the revision number from a working copy there is the vcs-revision package on Hackage (only SVN, Git and Mercurial support ATM).

@ghost ghost assigned 23Skidoo Sep 13, 2013
@dcoutts
Copy link
Contributor

dcoutts commented Sep 19, 2013

Please please lets not start using the versionTags for anything! We're trying to eliminate the tags from the Version type completely.

But totally fine with providing this info in that module (or indeed starting a second module with version and other non-path info).

Related to this revision concept is the hackage revision concept in the new hackage-2. I think we should consider these together so we don't end up with a mess. Hackage 2 will allow editing the .cabal file without updating the tarball, an to track those changes it currently uses a x-hackage-revisionfield (which we may change an incorporate into a proper field if/when we decide the design is right). On the other hand, the hackage revision is not supposed to change the package contents, so perhaps it is not right to include it into the generated module. But including the list of dependencies and versions on the other hand would be perfectly reasonable, or indeed other details about the configuration. And while I'm thinking about it, I think everything in that module should be marked NOINLINE to stop changes in config triggering too many recompiles.

@23Skidoo
Copy link
Member Author

23Skidoo commented Nov 5, 2013

The problem with not using versionTags is that it will make it impossible to get the revision number given just a InstalledPackageInfo. The use case I have in mind is file name generation for cached setup executables.

@23Skidoo
Copy link
Member Author

Related: #3909.

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

No branches or pull requests

6 participants