[Haskell-cafe] install-dirs on Mac OS X

Mark Lentczner markl at glyphic.com
Tue Dec 22 01:55:13 EST 2009


I have been thinking about the location of installed Haskell package files on Mac OS X. The choice of location affects:
	GHC & other Haskell implementations
	Haskell Platform
	Cabal & cabal-install
	Haddock
If all those agreed on directory locations and layouts, I think the state of Haskell on Mac OS X would be nicer for users. In particular, my hope is for users to end up with an automatically complete Haddock documentation incorporating everything they install.


1) Packages the user installs --global

I noticed that the default location for global installation with cabal is on Mac OS X is /usr/local:

	install-dirs global
	  -- prefix: /usr/local

This then intermingles all the Haskell package files along with all sorts of other things that live in /usr/local and environs. While this is arguably convenient for executables that end up in /usr/local/bin (in most people's PATH), it does make things less than tidy, and harder to clean up.

Taking a cue from the various preinstalled language systems on Mac OS X, up over in /Library might be a better place:

	Python puts installed packages in:
	/Library/Python/<version>/site-packages

	Ruby puts installed packages in:
	/Library/Ruby/Gems/<version>
	/Library/Ruby/Site/<version>

	Java appears to use
	/Library/Java/Extensions
	and has a link to the packages that come the framework as:
	/Library/Java/Home

	Perl put installed packages in:
	/Library/Perl/<version>

I suggest that the default place for global installs on Mac OS X be:
	/Library/Haskell/

Since cabal already by default interposes the compiler version into the lib dir, path, there doesn't appear to be a need to put a <version> dir level near the top.


2) Structure of package pieces

I notice that cabal/cabal-install's default layout of where a package's pieces go, and GHC's layout of its base packages don't agree. Further, cabal/cabal-install's are not set up so that one can easily delete an installed package without hunting down its parts.

cabal/cabal-install defaults the parts as follows:
   executables: --prefix--/bin
   libraries:   --prefix--/lib/--pkgid--/--compiler--
   data:        --prefix--/share/--pkgid--
   doc:         --prefix--/share/doc/--pkgid--/
   html:        --prefix--/share/doc/--pkgid--/html
That's at least four directories you need to hunt down if you want to clean out a package, and rummaging through bin to figure out which things to remove. (Not to mention libexec, which isn't used by any packages on my system, so I can't say where it goes...)

GHC/Haskell Platform use a different layout:
   executables: --prefix--/bin
   libraries:   --prefix--/lib/--compiler--/--pkgid--
   data:        --prefix--/share/--pkgid--
   doc:         --prefix--/share/doc/ghc/libraries/--pkgid--/
   html:        --prefix--/share/doc/ghc/libraries/--pkgid--/

I think it best if everything for a package is in one place - making removal very easy:
   executables: --prefix--/packages/--pkgid--/bin
   libraries:   --prefix--/packages/--pkgid--/lib/--compiler--
   data:        --prefix--/packages/--pkgid--/share
   doc:         --prefix--/packages/--pkgid--/doc
   html:        --prefix--/packages/--pkgid--/doc
I put the "packages" level at the top, so that other things, like a master Haddock index dir could be put easily directly under the prefix.


3) Symlinks for binaries

This does suggest that it would be nice for the symlink-bindir facility (is that in cabal itself, or added by cabal-install?) to have a version for --global installs. Users could then either set something like:
	symlink-global-bindir: /usr/local/bin
in .cabal/config.

Or
	symlink-global-bindir: /Library/Haskell/bin
and then put that in their PATH


4) Quick access to the Framework

I like Java's convenience link 'Home', and suggest that
	/Library/Haskell/GHC
be a symlink to where the framework's package files are stored:
	/Library/Frameworks/GHC.framework/Versions/Current/usr/

Other implementations could use the same idea.

Having this here would also (I suspect) help in getting Haddock to be able to find all the bits needed to generate a comprehensive index.


Thoughts? I'd be happy to help by supplying patches for various tools to normalize all this on some agreed upon layout. I admit that I'm a bit unclear where the directory choices are being made: Haskell Platform's build process, or GHC's?  Cabal's defaults or cabal-install's?  And then clearly parts of Haddock. Given the number of tools that need to agree, seems best that we hash it out (here or in the wiki) first, before making patches.

	- Mark (mtnviewmark)

Mark Lentczner
http://www.ozonehouse.com/mark/
mark at glyphic.com





More information about the Haskell-Cafe mailing list