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

[Xavier Leroy <Xavier.Leroy@inria.fr>]

> 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