Dynamic Libraries on MacOS X

[Simon Marlow]

> And there's a problem: ghc-pkg uses Read, and that requires all the=20
> fields to be there. It would be a Bad Idea to force everyone=20
> to update=20
> every single package.conf file out there. Is there any special reason=20
> why it doesn't use the ParsePkgConf.y parser from=20
> compiler/main? (Simon: Am I allowed to make it do so?)

Sure, go ahead.  That's been on my ToDo list for a while.

I'm beginning to think that the way MacOS X does frameworks is the way
we should have done packages: it's much simpler to install/remove
packages ("xcopy install" in MS-speak) if they all hang off a common
root.  On the other hand, it wouldn't be possible to install packages in
some non-standard place without giving GHC an extra flag each time you
use the package. =20

> > One interesting possibility would be to allow support for=20
> .hi files in
> > frameworks. This would mean GHC would look inside=20
> frameworks specified=20
> > by
> > the -framework flag and "frameworks" package.conf entries=20
> for .hi files,
> > in addition to -I and "import_dirs".
>=20
> I don't see why I would want to add a Haskell-Framework to a=20
> package.conf file... I would definitely like to be able to=20
> drag&drop-install GHC-Packages (it could be done on all=20
> platforms, not=20
> only MacOS). It would require loading package.conf files from=20
> framework-style directories - I'll take a look at whether=20
> this could be=20
> done easily (and without disturbing the existing system) when=20
> I've got the more important things done.

This does indeed sound useful, and perhaps it could co-exist with the
existing global package.conf file: if a package isn't found in
package.conf, then we just search the framework/package search path for
<package>/pkg.conf.  I'm sure this would make people distributing 3rd
party packages happier.

Cheers,
	Simon