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 AAA28807; Sun, 29 Apr 2001 00:26:10 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA28801 for ; Sun, 29 Apr 2001 00:26:09 +0200 (MET DST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f3SMQ7r17101 for ; Sun, 29 Apr 2001 00:26:07 +0200 (MET DST) Received: from localhost (patrick@localhost) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3SMQVc05346; Sat, 28 Apr 2001 18:26:31 -0400 (EDT) (envelope-from patrick@watson.org) Date: Sat, 28 Apr 2001 18:26:30 -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.20010428103832.00e244c0@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: > > >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