avoid PATH_MAX limitations on windows

[dcoutts]

When using nix style package ids, we get very long paths, e.g.

C:\Users\hvr\AppData\Roaming/cabal/store/ghc-8.0.0.20160421/unordered-containers-0.2.7.0-983a8e913817af8e0a8d0bb61ab730ac015f7cd650d0c8e1f28eac6ab8b068a8/lib/libHSunordered-containers-0.2.7.0-983a8e913817af8e0a8d0bb61ab730ac015f7cd650d0c8e1f28eac6ab8b068a8.a

This is 258 chars long. The Windows max path is 260 (including the driver letter etc).

While it's certainly possible to use the Windows APIs to get long file name support, all the programs that work with these files have to support that, this includes not just cabal but ghc, gcc, linker utils etc. So it is impractical to take that approach. The only workable approach is to keep the lengths down.

Given that we are using a nix style store, there is no reason to include the full package id into the paths within each store entry. While we can link multiple versions of a package into one exe, we cannot link multiple instances of the same package (right @ezyang) in which case we don't need to duplicate the id into the .a library name.

When did this change incidentally? We used to only use the package name + version for the lib name.

[sopvop]

I believe thats one of the resons why nix uses hash-clampedname format

[dcoutts]

@sopvop Can you point me to more details about that?

What I'm trying in the patch #3431 is to truncate both the package name (and version) and also truncate the hash size. So the max package id is 64 chars. How does that compare to what nix does?

[sopvop]

Nix did same as you do. And I'm not sure they clamp name anymore, at least not on my new nixos machine.

And I guess you should have used base32 after all.

nix uses hash first so it's easier to find store path by 2-4 letter prefix FAQ

[dcoutts]

Thanks, interesting reference.

[23Skidoo]

Fixed by #3431, I believe.

[23Skidoo]

Reopening because I want to backport this into 1.24.0.1.