windows ocaml

windows ocaml

[skaller]

Hi, we're having a terrible time getting ocaml to work properly
on Windows. This is with 3.09 native build.

1. ocamlc makes a bytecode file without an extension, which
cannot be executed. Ocamlopt adds '.exe'. This is inconsistent.

2. ocamlc makes a bytecode file which, when you add .exe
to the end can't exec ocamlrun .. even though it is in the PATH.
ocamlrun filename works fine.

The way our build scripts are set up, we assume the generated
file from a link step is executable (as for native code compiler).
For transparency, the generated bytecode must use the same filename
(.exe must be added) and the bytecode must actually run.

It looks like the bytecode is binding the wrong ocamlrun location,
if the bytecode file is copied to the same directory as contains
ocamlrun, it runs .. otherwise it fails.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] windows ocaml

[Christophe TROESTLER]

On Tue, 19 Jun 2007, skaller <skaller@users.sourceforge.net> wrote:
> 
> on Windows. This is with 3.09 native build.

Here is what I get for 3.10, MSVC.

> 1. ocamlc makes a bytecode file without an extension, which
> cannot be executed. Ocamlopt adds '.exe'. This is inconsistent.

ocamlc without -o produces camlprog.exe

> 2. ocamlc makes a bytecode file which, when you add .exe
> to the end can't exec ocamlrun .. even though it is in the PATH.
> ocamlrun filename works fine.

  ocamlc -o a.exe a.ml

produces a prefectly runnable executable (just typing 'a.exe').

> For transparency, the generated bytecode must use the same filename
> (.exe must be added) and the bytecode must actually run.
   ^^^^^^^^^^^^^^^^^^
Isn't it your own choice when you use the -o flag?

> It looks like the bytecode is binding the wrong ocamlrun location,

Maybe you have several ones installed??

My 0.02€,
ChriS

Re: [Caml-list] windows ocaml

[skaller]

On Tue, 2007-06-19 at 09:28 +0200, Christophe TROESTLER wrote:
> On Tue, 19 Jun 2007, skaller <skaller@users.sourceforge.net> wrote:
> > 
> > on Windows. This is with 3.09 native build.
> 
> Here is what I get for 3.10, MSVC.
> 
> > 1. ocamlc makes a bytecode file without an extension, which
> > cannot be executed. Ocamlopt adds '.exe'. This is inconsistent.
> 
> ocamlc without -o produces camlprog.exe

We're using -o I believe ..

	ocamlopt -o fred

produces fred.exe not merely fred AFAIK (not on Windows now).
This is inconsistent, it broke our build script when we switched
from ocamlopt to ocamlc.

> > 2. ocamlc makes a bytecode file which, when you add .exe
> > to the end can't exec ocamlrun .. even though it is in the PATH.
> > ocamlrun filename works fine.
> 
>   ocamlc -o a.exe a.ml
> 
> produces a prefectly runnable executable (just typing 'a.exe').

That worked for us too .. if, and only if, the current directory
contained ocamlrun.exe. I have no idea why, but there's no question
that 3.09 bytecode is NOT looking in the PATH, because

	ocamlrun filename

actually works (where filename is the bytecode file).

> > For transparency, the generated bytecode must use the same filename
> > (.exe must be added) and the bytecode must actually run.
>    ^^^^^^^^^^^^^^^^^^
> Isn't it your own choice when you use the -o flag?

If that were the case the native code compiler should
also not add .exe .. but it does (I think -- not on Windows 
at the moment).

> > It looks like the bytecode is binding the wrong ocamlrun location,
> 
> Maybe you have several ones installed??

There are two, the other one is in Cygwin though, so it 
shouldn't be involved. Besides 'ocamlrun' as the command
found in the PATH actually works.

BTW: we're only messing around with bytecode because either
Ocamlopt is broken by a stack overflow compiling a dypgen
generated grammar (ml file), or dypgen is broken by 
stack overflow when compiling generating it.

It all works on Linux, but fails
one way or the other on OSX (ppc), Cygwin, Windows native
port, mingw (Cywgin -mnocygwin), and I think OSC (x86).

The bytecode compilers generating bytecode seem to handle
it on those platforms we've actually managed to get
it running on.

It's possible some of the problems will go away after
Garrigue's quadratic reducing patch to polymorphic variants,
since the only real 'bigness' in the dypgen generated file is lots 
of polymorphic variants, and several functions per constructor ..
mostly chained together in a large 'let' binding.

Still, can't see why any of that would trash an 8Meg stack.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net