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