RE: [Caml-list] minor suggestions for Win32 port

RE: [Caml-list] minor suggestions for Win32 port

[Lionel Fourquaux]

> -----Message d'origine-----
> De : owner-caml-list@pauillac.inria.fr
> [mailto:owner-caml-list@pauillac.inria.fr]De la part de Chris Hecker
> Envoyé : samedi 7 avril 2001 05:15
> À : caml-list@inria.fr
> Objet : [Caml-list] minor suggestions for Win32 port
>
>
>
> 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.
>

	What about calling link.exe directly?



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

Re: [Caml-list] minor suggestions for Win32 port

[Xavier Leroy]

> 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.

I can't say I fully understand all the issues, but if you can sort
them out and send me a patch, I'll be very happy.  Concerning Lionel
Fourquaux's suggestion of calling link.exe directly, this can also be
considered, although for "ocamlc -custom" we also need to call the C
compiler to compile a small chunk of generated C code.

> 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.

The Sys.command OCaml function knows how to use a response file if the
command-line is too long (see byterun/win32.c, function win32_system()).
However, it is calibrated for Win NT/2K, where the maximal length of a
command line is circa 1000 characters.  I can reduce the maximal
length to what Win9x tolerates, although the best solution would be to
find out at run-time the max length that the system tolerates.  (Going
through response files when not absolutely necessary is a bit of a
problem, since the command that we're calling might not understand
response files, so better avoid them if at all possible.)
Any ideas on how to do this in Win32?

> 3.  [...] 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/.

Right, currently the source distribution contains just a Unix boostrap
compiler, which (barely) suffices to bring the system up to speed even
under Win32.  To address the problem you had, it should be enough
to do "nmake -f Makefile.nt bootstrap", which completes the bootstrap
so that the boot compilers and the generated compilers are identical
(and Win32-aware).

> 4.  Have the makefile.nt put the .exe extension on all the output
>     files.

I must have missed a few .exe extensions.  Again, if you happen to
have patches handy...

Cheers,

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

[Caml-list] minor suggestions for Win32 port

[Chris Hecker]

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