Default install locations on Windows
Duncan Coutts
duncan.coutts at googlemail.com
Sun Dec 27 12:42:17 EST 2009
All,
For Cabal packages our default install locations on Windows are a bit of
a mess.
Firstly we do global installs by default. This used to make sense on
Windows XP when everyone had admin permissions. It no longer makes sense
for Vista or Windows 7. See this recent horror story from a new user:
http://haskell.org/pipermail/haskell-cafe/2009-December/071310.html
I've talked for a while about switching the default to per-user installs
on Windows:
http://hackage.haskell.org/trac/hackage/ticket/465
Now I'm not a regular Windows user so I would like some expert advice
from Windows Haskell hackers. Specifically, are the default locations
and layout for per-user installs OK?
A related problem is that historically we tried to fudge things so that
packages could be mostly relocatable by default. This is because Windows
tends to make greater use of relocatable packages (giving users a choice
of location at install time). There is a problem with relocatable
packages that depend on libraries that contain data files:
http://hackage.haskell.org/trac/hackage/ticket/466
My proposed solution for this is to not do anything special about data
files for windows and use the same directory layout as on Unix. That is,
change:
datadir = case buildOS of
Windows | hasLibs -> windowsProgramFilesDir </> "Haskell"
| otherwise -> "$prefix"
_other -> "$prefix" </> "share",
to
datadir = case buildOS of
Windows -> "$prefix"
_other -> "$prefix" </> "share",
BTW, why do we not want the "share" subdir? It means currently we end up
with a per-package directory at the top level containing the data files
for that package.
So then the per-user install locations on Windows 7 would be:
prefix: C:\Users\${USER}\AppData\Roaming\cabal
bindir: $prefix\bin
libdir: $prefix
libsubdir: $pkgid\$compiler
libexecdir: $prefix\$pkgid
datadir: $prefix
datasubdir: $pkgid
docdir: $prefix\doc\$pkgid
htmldir: $docdir\html
haddockdir: $htmldir
Then separately I think we need explicit support for constructing prefix
independent packages which could check for these issues. eg:
cabal configure --prefix-independent
Duncan
More information about the cabal-devel
mailing list