Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] library packaging
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: james woodyatt <jhw@w...>
Subject: [Caml-list] library packaging

Again, the subject of application packaging has arisen on the list (this 
time in a thread about the size of statically-linked native-code 
executables), and I would like to share my thoughts on the subject.

I'd like to see a way to link with shared libraries in native-code 
executables.  I'd also like to see a way to load and unload objects 
dynamically at runtime in native-code executables.  These are about the 
only things I really miss in Objective Caml now, and I think they can be 
added-- but it will take some work.

I'm beginning to think that what I really want is something like the 
Darwin application bundle and framework model.

A Darwin application bundle comprises all the application-specific 
libraries, shared objects, resources, executable programs and private 
frameworks that makes an application a unit.

A Darwin application framework (including the private frameworks 
contained in application bundles) comprises all available versions of a 
library, as well as the corresponding interface definitions for each.

The Darwin port of the Gnu Compiler Collection extends the command-line 
interface of the GCC command driver with a -framework option, which is 
very much like how the ocamlfind driver works in findlib-0.6.1.  Except: 
the native-code images output by the linker may be linked with 
dynamically-linked (as well as statically-linked) libraries to be loaded 
from named frameworks, and frameworks on the system are searched at 
load-time for the correct versions of dynamic libraries.

The search order of frameworks is defined by the system: use private 
frameworks first; next use system frameworks; then use application 
frameworks installed in a system library; lastly and optionally, search 
application frameworks installed in a network library on remote volume.

I think a lot of the problems folks are surfacing on the list about 
application packaging and dynamic loading are well-addressed in the 
Darwin design.  Before we launch into yet another discussion of the 
problem, I would suggest having a look at the relevant chapters in the 
System Overview on Apple's Mac OS X developer documentation site.  It's 
free (but might require registration, I'm not sure):

There is a PDF version of this document you can download from the site.  
Ask me to mail it to you, if you would rather have it that way.

j h woodyatt <>
"You're standing on sacred ground.  Many strange and wonderful
things have transpired right where you're standing."  --unattributable

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: