Cabal-1.22 keyed library filepaths
Edward Z. Yang
ezyang at mit.edu
Sun Feb 8 22:10:43 UTC 2015
Jens, could file a Cabal bug for the contents of this email?
Excerpts from Edward Z. Yang's message of 2015-01-18 22:47:23 -0800:
> Hey Jens,
> The motivation for truncating the names and version was to keep
> symbol name sizes manageable even with the addition of the hash,
> while giving at least some hint when working with the symbols
> directly. It doesn't seem that this rationale applies for library
> names, so it's possible we could separate these (in any case, only
> the hash really matters: the package name/version are included
> in the hash), but we'd have to figure out where in the current codebase
> makes assumptions about this.
> Excerpts from Jens Petersen's message of 2015-01-18 17:54:34 -0800:
> > Hi,
> > I see that with Cabal-1.22, library paths are now of the form:
> > /usr/lib64/ghc-126.96.36.19941222/direc_3m6Ew9I164U5MIkATLCdb8/
> > libHSdirec_3m6Ew9I164U5MIkATLCdb8-ghc188.8.131.5241222.so
> > etc.
> > Is the 5 character truncation of package names (and no version) necessary?
> > It makes it pretty hard to see at a glance what package a particular
> > directory or file belongs to and seems there is no easy way to work out the
> > package version without referring to the package.conf file/dir.
> > If possible I would prefer a filepath format like:
> > /usr/lib64/ghc-184.108.40.20641222/directory-220.127.116.11_3m6Ew9I164U5MIkATLCdb8/
> > libHSdirectory-18.104.22.168_3m6Ew9I164U5MIkATLCdb8-ghc22.214.171.12441222.so
> > Would that be feasible/make sense?
> > Jens
More information about the cabal-devel