From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA07164; Sun, 29 Apr 2001 18:44:24 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA06934 for ; Sun, 29 Apr 2001 18:44:23 +0200 (MET DST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f3TGiMH12353 for ; Sun, 29 Apr 2001 18:44:22 +0200 (MET DST) Received: from localhost (patrick@localhost) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3TGiYc16052; Sun, 29 Apr 2001 12:44:34 -0400 (EDT) (envelope-from patrick@watson.org) Date: Sun, 29 Apr 2001 12:44:34 -0400 (EDT) From: Patrick M Doane To: Chris Hecker cc: caml-list@inria.fr Subject: Re: [Caml-list] ocamlmktop and includes In-Reply-To: <4.3.2.7.2.20010428224507.02ebccf0@shell16.ba.best.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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