> And there's a problem: ghc-pkg uses Read, and that requires all the
> fields to be there. It would be a Bad Idea to force everyone
> to update
> every single package.conf file out there. Is there any special reason
> why it doesn't use the ParsePkgConf.y parser from
> 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.
> > One interesting possibility would be to allow support for
> .hi files in
> > frameworks. This would mean GHC would look inside
> frameworks specified
> > by
> > the -framework flag and "frameworks" package.conf entries
> for .hi files,
> > in addition to -I and "import_dirs".
>
> I don't see why I would want to add a Haskell-Framework to a
> package.conf file... I would definitely like to be able to
> drag&drop-install GHC-Packages (it could be done on all
> platforms, not
> only MacOS). It would require loading package.conf files from
> framework-style directories - I'll take a look at whether
> this could be
> done easily (and without disturbing the existing system) when
> 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
_______________________________________________
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
