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
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.
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.
The text was updated successfully, but these errors were encountered:
@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.
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.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.
The text was updated successfully, but these errors were encountered: