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 GAA15074; Sat, 7 Apr 2001 06:03:56 +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 GAA15070 for ; Sat, 7 Apr 2001 06:03:56 +0200 (MET DST) Received: from smtp4-cm.mail.eni.net (smtp4-cm.mail.eni.net [216.133.226.137]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f3743sv08388 for ; Sat, 7 Apr 2001 06:03:55 +0200 (MET DST) Received: from CHECKERATH (node-d8e9cca2.powerinter.net [216.233.204.162]) by smtp4-cm.mail.eni.net (8.9.3/8.9.3) with SMTP id UAA24087; Fri, 6 Apr 2001 20:14:42 -0700 Date: Fri, 6 Apr 2001 20:14:42 -0700 Message-Id: <200104070314.UAA24087@smtp4-cm.mail.eni.net> From: Chris Hecker To: caml-list@inria.fr Subject: [Caml-list] minor suggestions for Win32 port Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Here are some minor suggestions and feature requests I've come up with while working with the Win32 MSVC ocaml port (3.00 and 3.01). 1. If you're using the MSVC cl.exe compiler, it sends linker command line parameters in a relatively broken way, so this affects the -cclib switch. Basically, to pass parms to link.exe from cl.exe, you say /link [and then all the parms], so you can't have any compiler flags after linker flags. You also don't know if a library you're building is going to be linked with other libraries with -cclib parms, so you have to do this: -cclib "/link /debug /whatever", but then you get duped parms to the linker and it complains, etc. It's basically hard to get it exactly right. The right thing to do here is have the msvc driver know this, and store the cclib parms up, sort/uniq them, and then put them after a /link itself. 2. Win9x, pile of dung that it is, has rather strict command line length limitations. Since ocaml tries to pass all the objs and whatnot on the command line for the final link, it fails with big projects on Win9x. The solution to this is to use a "response file". A response file is a tmp file you write out with all the parms, and then call the compiler like this: "cl.exe @/tmp/rsp.tmp" and it reads the response file as if it was a command line. 3. I'm trying to track down a really weird hang with emacs and an inferior-caml toplevel on Win2k (but not Win98, go figure), so I decided I'd add a call to an external C function that does an x86 "int 3" breakpoint interrupt in the toploop.ml file right above where it gets the char from stdin. Anyway, all hell broke loose trying to build this in, and I finally tracked it down to the fact that the boot/ocamlc file in the tarball was compiled on Linux (or at least with the cygwin stuff), so its rules for adding object files and linking -custom bytecode apps are incompatible with VC (namely, it looks for .o files, not .objs, and it tries to spawn gcc rather than link.exe or cl.exe). Once I figured this out I was able to build by putting a VC ocamlc into boot/. Anyway, this brings me to this suggestion: Have two versions of the boot/ocamlc executable in the source distribution, one that has .o/gcc built in and one that uses .obj/cl/link. Have the config/Makefile.nt specify which to use for bootstrapping. Or, and this is probably more general, have ocamlc optionally read environment variables to get the ClFlags stuff, and these can be used during bootstrapping. 4. Have the makefile.nt put the .exe extension on all the output files. I'll probably make a few of these changes myself as I work. Is anybody else running into these problems? If so, I can try to make the changes in a relatively non-hacked way and send in the diffs. But, if no one else cares, I won't waste time making the changes general. Chris ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr