On Sat, 28 Apr 2001, Chris Hecker wrote:

> 
> >Alternatively, it would be really nice to make stand-alone byte code
> >interpreters which have the .cmo files builtin.
> 
> Do you just mean a standalone executable (with no need for ocamlrun)? 
> If so, use the "-custom" flag to ocamlc and it'll put the intepreter
> inside the output file (and it appears the file is still recognized as a
> bytecode file by ocamlrun, so it's still portable as long as you don't
> link any C objects into it).  Maybe that's not what you meant... 

For some additional context,  I'm trying to create a front-end for
regression testing.  I would like to have a top-level application which
can execute O'caml scripts with an additional module preloaded. It was
pretty easy to use ocamlmktop to build my module into a top-level
interpeter. Unfortunately, the user then has to supply the location of my
module to use it.  I was hoping to provide a single executable that could
be used to run the scripts.

The '-custom' flag might do the trick.  I'm not too worried about
requiring ocamlrun to be on the same machine though.

> Putting the include paths in the generated toplevel sounds like a good
> idea to me.  I decided to implement this.  I've attached the new
> tools/ocamlmktop.ml below.  You should be able to build this by itself
> with "ocamlc -o ocamlmktop ocamlmktop", without building the compiler or
> even having the compiler source installed. 

Ah, very good.  I'll try this out and let you know how it works.

> Random Notes & Issues:
> 
> - I need to build a temp .ml file and compile it, which assumes the
>   ocamlc compiler is around.  Of course, ocamlmktop already assumes
>   this. 

Certainly reasonable.

> - I use Topdirs.dir_directory to add the include directories...I doubt
> it's supposed to be an exposed API. 

I think there is some intent for the toplevel commands to be exposed APIs.
I remember seeing a comment in one of those modules about allowing custom
top-levels to call them.

It would be great for the APIs to be officially documented and supported.
I've had to do a bit of hacking using the toplevel commands to implement
the regression testing.  This includes the need to save/restore an
environment and execute an external script.

> - It expands directories at runtime, so if you add -I +foo it'll work
> even if you move CAMLLIB. 

That's handy!

> - What you probably really want here is a new command line parm so you
>   can differentiate betwen include dirs that should be added to the
>   toplevel and those that shouldn't. 

My initial expectation was that building a top-level interpreter would
link the object files into that interpeter.  That maybe an alternative
approach to addressing this issue.

Thanks for your help,
Patrick

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr