RE: Dynamic Libraries on MacOS X
> 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
/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
Re: Dynamic Libraries on MacOS X
On Dienstag, Juni 11, 2002, at 09:22 , Ashley Yakeley wrote: > They solve a similar problem in a quite different way. [...] > I think Wolfgang means [...] Exactly. > [...] add new package specification components, such as > "frameworks" and "frameworks_dir". They just need to be passed on to the > linker. 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?) > 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. Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Dynamic Libraries on MacOS X
At 2002-06-10 04:03, Simon Marlow wrote: >It sounds like frameworks are similar in concept to GHC's packages. They solve a similar problem in a quite different way. A framework is a "bundle": an actual directory with everything inside it, libraries, header files, localised strings, whatever, with a particular internal structure that does clever stuff with symbolic links to handle multiple versions. Frameworks and other bundles (such as applications) may be relocated by the user, though frameworks generally need to be in certain standard places so that other tools can find them. Bundles may be uninstalled simply by deleting the directory. Generally the Mac GUI shows the directory as an object rather than a folder, though there's a special menu option to open the directory up like any folder. By contrast, GHC packages are virtual i.e. the stuff is not necessarily all in one directory. And if any of it gets moved, the package.conf file would need to be updated. For code-generating tools, you point to frameworks on the command-line much as you do libraries. For instance, just as you do "-lfoo -L./foolibs" to refer to libfoo and to search for libraries in ./foolibs/, you'd do "-framework foo -F ./foofws" to refer to foo.framework and to search in ./foofws/ for frameworks (there are also standard places to search). The Darwin C compiler can use this to find include files, and then you can pass the same options to the linker, and it will find the libraries. Too bad frameworks aren't standard on all UNIX, they are an excellent way of packaging software. >> *) add two command line options that get passed on to the >> linker (-framework for linking with a framework and -F for >> specifying framework search paths) >> *) add corresponding entries to package.conf > >You mean add a new package for each framework? I think Wolfgang means add new package specification components, such as "frameworks" and "frameworks_dir". They just need to be passed on to the linker. 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". This would mean a bit more code but I believe Apple provides APIs for dealing with bundles easily. -- Ashley Yakeley, Seattle WA ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Dynamic Libraries on MacOS X
> Possible Solution: > Frameworks. A "Framework" on MacOS X is a directory that > contains a dynamic library plus associated resources and > header files. There is an extra compiler/linker option for > linking to a framework. The big advantage is that the place > they are supposed to be installed in is accessible from the > user interface. > I've created a framework called "HaskellSupport.framework", > and I've made ghc link to that. It sounds like frameworks are similar in concept to GHC's packages. It's usually a good idea to comply with whatever is the approved way of doing things on a given platform, so I think this sounds like a reasonable solution. > Disadvantage: > Problems with GHCi (yes, I've almost got it to work!) - > "-framework HaskellSupport" is in the extra_ld_opts field of > the RTS package, so GHCi doesn't know that it has to load the > libraries. That sounds fine... as long as HaskellSupport doesn't contain any static libraries, right? > Related Problem: > Sooner or later, GHC for MacOS X should support Apple's > Frameworks anyway, as almost all functionality beyond the > standard C library is packaged in frameworks. I don't know > yet how much work that would be for me, and I fear that the > ghc gurus would dislike too much platform-specific code for > Apple's non-standard features... Here's what I'd like to do: I don't object at all to adding MacOS X specific code for frameworks, as long as there's someone around to maintain it! > *) add two command line options that get passed on to the > linker (-framework for linking with a framework and -F for > specifying framework search paths) > *) add corresponding entries to package.conf You mean add a new package for each framework? That's what I would suggest, if it is at all possible. If that's the case, then is the -framework option needed at all, since you can use -package instead? > *) add code for GHCi to load frameworks. Same here: if a framework is really just a collection of libraries and a search path, then converting frameworks into packages will mean that GHCi can load them as normal. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
