Re: [Caml-list] Executable size?

[skaller <skaller@ozemail.com.au>]

On Sun, 2003-11-16 at 02:13, John J Lee wrote:
> On Sat, 16 Nov 2003, skaller wrote:

> > The Ocaml equivalent of a C stub program which dynamically
> > links to the C run time is bytecode.
> 
> And, you're implying, even C's "hello world" *is* using the C standard
> library, because of printf -- and O'Caml is using it's standard library
> for the same reason.  

I think I'm saying that a 'fair' comparison would be between
C shared library partitioning of code, and Ocaml driver
program (top level) which loads bytcode dynamically:
when Ocaml is statically linking native code it is going
for all out blinding speed and ease of moving the
application executable around, instead of a small footprint
and portability of the application.


> So, an O'Caml .DLL or .so is implemented using O'Caml bytecode?

If you want dynamic loading, you have to use either bytecode
or a patched native code compiler (at least on the x86/Linux
platform).

This is a bit of a pain, I'd love to generate shared libraries.
[I only use the native code system]

> 
> > In my opinion, you best bet is to generate bytecode
> > and distribute that. Your clients WILL have to download
> > the bigger ocamlrun driver harness, but hopefully
> > only once.
> 
> That's not useful in the case where the user is only downloading one
> program, unfortunately.

True it will not reduce the footprint. Perhaps it will even be
larger. However, it *will* help make the code more portable,
since you can separate the one off task of building a custom
top level for each platform, and then building platform independent
application code.

I do this in Felix, and luckily for me the standard toplevel
has all the resources I need, so I can just rely on the Ocaml
team to build toplevels for each system, and let the client
build my product using bytecode if there is no native 
compiler for their platform.

If you do that, the footprint will vary depending on
the target platform. (Which it will anyhow I suppose :-)


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners