Re: [Caml-list] Ocaml 3.03 alpha MinGW port

Re: [Caml-list] Ocaml 3.03 alpha MinGW port

[Jean-Marc Eber]

There have been some interesting postings on this list
about a MinGW port of the OCaml Compiler. The
attached patch was textually large but conceptually
simple.

I'm really not a specialist about this topic, but have now
(or in a near future) to choose between possible
Windows "technologies" (Visual C, Cygwin, MinGW) for
an OCaml program (only a console mode stuff in my case).

Could anybody explain to me why a MinGW isn't *always*
preferable to a Cygwin one (use of the same compiler, GCC,
MinGW being more "direct" Windows without an indirection
layer, not speaking about licensing problems, etc....).

I understand well that the Caml Team wants probably to
maintain a MS C version of the OCaml implementation,
but wanted to ask the Team if they have some ideas about
the future of Cygwin/MinGW ports. Isn't a MinGW port, in
the medium term, preferable to a Cygwin one ? Or do I
miss a point ?

Jean-Marc Eber
LexiFi



-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Ocaml 3.03 alpha MinGW port

[Xavier Leroy]

> I'm really not a specialist about this topic, but have now
> (or in a near future) to choose between possible
> Windows "technologies" (Visual C, Cygwin, MinGW) for
> an OCaml program (only a console mode stuff in my case).
> 
> Could anybody explain to me why a MinGW isn't *always*
> preferable to a Cygwin one (use of the same compiler, GCC,
> MinGW being more "direct" Windows without an indirection
> layer, not speaking about licensing problems, etc....).

The full Cygwin provides a rather complete Unix emulation, hence the
OCaml Cygwin port supports the debugger, all of the Unix module, and
(I believe) the LablGTK GUI -- all things that are missing in the
OCaml MinGW port, if I remember correctly.

> I understand well that the Caml Team wants probably to
> maintain a MS C version of the OCaml implementation,
> but wanted to ask the Team if they have some ideas about
> the future of Cygwin/MinGW ports. Isn't a MinGW port, in
> the medium term, preferable to a Cygwin one ? Or do I
> miss a point ?

The situation is quite simple, really:

- We can't support three different Windows port of OCaml; the current
  two are already too much.

- Every time I mention this fact on this list, we get replies of the form
    "I can't live without the Visual C based port of OCaml --
     I'm doing real industrial work, and everything gcc-related is
     just amateur work"
  OR
    "I got a Windows machine because that's the company policy,
     but I really do all my work within the Cygwin environment and
     don't want to hear about anything else".

Draw your own conclusions...

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Ocaml 3.03 alpha MinGW port

[Dmitry Bely]

Xavier Leroy <xavier.leroy@inria.fr> writes:

> > I'm really not a specialist about this topic, but have now
> > (or in a near future) to choose between possible
> > Windows "technologies" (Visual C, Cygwin, MinGW) for
> > an OCaml program (only a console mode stuff in my case).
> > 
> > Could anybody explain to me why a MinGW isn't *always*
> > preferable to a Cygwin one (use of the same compiler, GCC,
> > MinGW being more "direct" Windows without an indirection
> > layer, not speaking about licensing problems, etc....).
> 
> The full Cygwin provides a rather complete Unix emulation, hence the
> OCaml Cygwin port supports the debugger, all of the Unix module,

Yes, MinGW port lacks that (as well as MSVC one -- that's Win32 without
fork() and other stuff). MSVC and MinGW ports support absolutely the same
set of OCaml libraries.

> and
> (I believe) the LablGTK GUI -- all things that are missing in the
> OCaml MinGW port, if I remember correctly.

Hmm, IIRC standard 3.03 alpha contains only LablTk, not LablGTK. Yes, with
MinGW patch LablTk can be compiled out of the box. As for LablGTK, it
also should not be a problem -- gtk/Win32 does not rely on Cygwin...

> > I understand well that the Caml Team wants probably to
> > maintain a MS C version of the OCaml implementation,
> > but wanted to ask the Team if they have some ideas about
> > the future of Cygwin/MinGW ports. Isn't a MinGW port, in
> > the medium term, preferable to a Cygwin one ? Or do I
> > miss a point ?
> 
> The situation is quite simple, really:
> 
> - We can't support three different Windows port of OCaml; the current
>   two are already too much.

MinGW port in fact do not need any extra support; it uses the same
sources as MSVC one (and even links with MS-supplied C runtime library
msvcrt.dll), and shares Make/Configure environment with all other Unixes. I
see no real problem here...

> - Every time I mention this fact on this list, we get replies of the form
>     "I can't live without the Visual C based port of OCaml --
>      I'm doing real industrial work, and everything gcc-related is
>      just amateur work"
>   OR
>     "I got a Windows machine because that's the company policy,
>      but I really do all my work within the Cygwin environment and
>      don't want to hear about anything else".
> 
> Draw your own conclusions...

OK, I do not insist. It really may not worth your efforts. I just thought
that for people, who cannot/does not want to buy expensive and
multimegabyte MSVC but need C compiler under Win32 (for custom runtimes,
CamlIDL etc), native Win32 port of OCaml, compiled with gcc compiler, would
be very convenient...

Hope to hear from you soon,
Dmitry


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

[Caml-list] Re: MinGW port

[Jean Martos]

Jean-Marc Eber a écrit :

> There have been some interesting postings on this list
> about a MinGW port of the OCaml Compiler. The
> attached patch was textually large but conceptually
> simple.
>
> I'm really not a specialist about this topic, but have now
> (or in a near future) to choose between possible
> Windows "technologies" (Visual C, Cygwin, MinGW) for
> an OCaml program (only a console mode stuff in my case).
>
> Could anybody explain to me why a MinGW isn't *always*
> preferable to a Cygwin one (use of the same compiler, GCC,
> MinGW being more "direct" Windows without an indirection
> layer, not speaking about licensing problems, etc....).
>
> I understand well that the Caml Team wants probably to
> maintain a MS C version of the OCaml implementation,
> but wanted to ask the Team if they have some ideas about
> the future of Cygwin/MinGW ports. Isn't a MinGW port, in
> the medium term, preferable to a Cygwin one ? Or do I
> miss a point ?
>
> Jean-Marc Eber
> LexiFi

Cygwin offers an emulation layer of the UNIX system calls. But if you compile using
Cygwin, you have to provide the cygnus.dll which contains the emulation layers.
And then, it is no so easy to mix both unix like system calls and native system
calls.

Msv compiler, by default (so for Ocaml), generated objects using I/O routines
provided by crtdll. (For example C++ woks this way). But a lot of programs use the
msvcrt.dll, which provides I/O routines which conflits with crtdll. So if you want
to mix  codes from ocaml and c for example, you must be coherent with the runtime
library (crt or msvcrt), or encapsulate your code in a DLL.

Mingw32 use the native system calls and the msvcrt.dll.

The problem arises when you want to mix code from a tool which generates code using
msvcrt.dll and Ocaml. For example, we have a program writing in GNAT and we use
Ocaml as an extension language. GNAT use gcc (mingw32) as backend to generate code.
To mix ADA code and Ocaml, we must isolate the ADA code or Ocaml code in a DLL. And
in our application it is not possible for a lot of reasons. So we have port Ocaml
for gcc-mingw32 and it works fine.

The work to port the core Ocaml for gcc-mingw32 is not very hard. It consists on a
very few changes in configure script, in asmrun and bytecomp.
The main problem is to adapt specific libraries like the native threads. But, I
have already take a look and it seems to be a little work to do it. The problem is
Time!!

Another problem is portability. And I just want to say that gcc on Window is not a
toy, but associated with all the gnu tools is a good mean, i think the best today,
to acheive portability betwen Unix and Windows. If you write code using Visual C++,
your application runs and only runs on Windows, the port to another platform can be
hard.

I unterstand the Ocaml team, when they say that they don't want to maintain 3 ports
on Windows. But I think that a lot of people, like us, want to use Ocaml with gcc
mingw32, and it will be fine to have an official mingw32 port.


Jean Martos.



>
> -------------------
> Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
> To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr