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
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
participants (2)
-
Ashley Yakeley -
Wolfgang Thaller