Skip to content

RFC consider including identifying infos from ghc --info in nix-style hash #5116

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
hvr opened this issue Feb 5, 2018 · 3 comments
Open

Comments

@hvr
Copy link
Member

hvr commented Feb 5, 2018

An annoying issue when working with GHC HEAD or other custom GHCs is that they tend to have overlapping GHC version numbers if you build multiple versions of GHC on the same day.

One important identifying detail however if provided by ghc --info: the git commit id from which a GHC executable was derived, e.g.

"Project Git commit id","0156a3d815b784510a980621fdcb9c5b23826f1e"

In future, maybe Hadrian could provide additional identifying fingerprints to disambiguate different GHC builds from each other.

But I think introducing the Git commit id would already help avoiding a class of subtle ABI incompatibilties between GHC snapshots sharing the same version number.

@23Skidoo
Copy link
Member

Makes sense.

@Ericson2314
Copy link
Collaborator

@ElvishJerricco pointed me here seeing my related idea from https://ghc.haskell.org/trac/ghc/ticket/11042#comment:31 where $CC -Wl,--trace be used to extra the location of all system libraries. I suppose actually doing that (vs relying on it being done) would be Cabal's job? This would likewise make the InstalledPackageInfo (and it's hashes) better reflect non-cabal-managed dependencies.

@ElvishJerricco
Copy link

Yea I consider this extremely-nice-to-have. Not blocking anything significant, but I'd rejoice at its implementation.

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

5 participants