On Sat, 28 Apr 2001, Chris Hecker wrote:

> 
> >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.
> 
> Yes, but you want both.  You link the .cmos (or .cmas) in, but you also
> need a path to their .cmi files, which is what the include dirs are for. 
> It might be nice if there was some way to also have the .cmi files
> onboard with the toplevel (or in libraries), so it was just all there
> with no need for other stuff.  I'm not going to implement that, though. 
> ;) 

I thought initially the include path was for the .cmo, but I see it is for
the .cmi files now.  I agree that having a mechanism to include the .cmi
files would work out very well.

My goal is to provide a application which can execute Caml source files. 
The source files should have access to some of the modules which are part
of the application. I'm not particularly interested in the interactive
aspect, but I want to make sure that the Caml source files do not need to
be compiled to byte-code before being exeucted.  My top-level application
should have its own command-line options and usage messages which are
separate from those provided by Topmain. 

My current approach to this goes through several layers of indirection:

1) Write my program with code to execute script files similarly to the
approach used in Topmain. 

2) Write a one line Caml script which calls the entry point to my program

3) Build a top-level interpreter using ocamlmktop for my program. 

4) Write a shell-script which calls the top-level interpreter with the
include directories for the .cmi files that I want the scripts to be able
to access and execute the one line Caml script.  All arugments passed to
the shell script are then forwarded to the entry point. 

I think I could remove some of these steps if it were possible to access
the Clflags.include_dirs variable.  The top-level code to execute a script
will only look for .cmi files in that directory. So to get around this, I
source a script in the traditional mechanism which can then source more
scripts.

Any thoughts on a better approach?

Patrick Doane

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