Pre-compiled ocaml binary for windows

Pre-compiled ocaml binary for windows

[José Romildo Malaquias]

Hello.

I am looking for a binary release of the latest ocaml compiler for
Windows. From the OCaml home page I can find only an older version
(3.11.0).

Where can I find the latest version?

Romildo

Re: [Caml-list] Pre-compiled ocaml binary for windows

[Damien Doligez]

Hello,

On 2010-12-03, at 21:06, José Romildo Malaquias wrote:

> Hello.
> 
> I am looking for a binary release of the latest ocaml compiler for
> Windows. From the OCaml home page I can find only an older version
> (3.11.0).
> 
> Where can I find the latest version?


It depends on which port you want.  For Cygwin, there is an up-to-date
cygwin package.  For the other ports, we are looking for volunteers to
compile and publish the binaries.

-- Damien

Re: Pre-compiled ocaml binary for windows

[Sylvain Le Gall]

Hello,

On 06-12-2010, Damien Doligez <damien.doligez@inria.fr> wrote:
> Hello,
>
> On 2010-12-03, at 21:06, José Romildo Malaquias wrote:
>
>> Hello.
>> 
>> I am looking for a binary release of the latest ocaml compiler for
>> Windows. From the OCaml home page I can find only an older version
>> (3.11.0).
>> 
>> Where can I find the latest version?
>
>
> It depends on which port you want.  For Cygwin, there is an up-to-date
> cygwin package.  For the other ports, we are looking for volunteers to
> compile and publish the binaries.
>

There is a start a .msi packaging of OCaml + flexdll + findlib:
https://forge.ocamlcore.org/projects/ocaml-installer/
http://hg.ocamlcore.org/cgi-bin/hgwebdir.cgi/ocaml-installer/ocaml-installer/

There are still problem and we are lacking a bit of time to finish it.
But hopefully, it will be finished one day. If anyone have time/knowledge,
we will be happy if he joins the OCaml Windows Installer project.

Regards,
Sylvain Le Gall

Re: [Caml-list] Re: Pre-compiled ocaml binary for windows

[Matthieu Dubuget]

Hello,

> There are still problem and we are lacking a bit of time to finish it.

could you explain the problems remaining?

Thanks for all your efforts

Matt

Re: Pre-compiled ocaml binary for windows

[Sylvain Le Gall]

On 06-12-2010, Matthieu Dubuget <matthieu.dubuget@gmail.com> wrote:
> Hello,
>
>> There are still problem and we are lacking a bit of time to finish it.
>
> could you explain the problems remaining?

Here is the list so far:
1. no build system setup : Martin who first did the packaging, didn't
   have included how to build ocaml/findlib neither the binaries itself.
   So basically you need to build by hand to generate the .msi. This is
   not a big issue but for a collective effort it is better to have a
   common way to build the binaries
2. some environment variables are not set and make ocaml crash (AFAIR, we
   doesn't set OCAMLIB)
3. we don't ship the graphical toplevel
4. I am still not sure how to deal with ActiveTCL + OCaml (because of the
   ActiveTCL license)
5. Total lack of documentation 


1. is mandatory to my mind.

Regards,
Sylvain Le Gall

Re: [Caml-list] Re: Pre-compiled ocaml binary for windows

[Alain Frisch]

On 12/07/2010 01:24 AM, Sylvain Le Gall wrote:
> Here is the list so far:
> 1. no build system setup : Martin who first did the packaging, didn't
>     have included how to build ocaml/findlib neither the binaries itself.
>     So basically you need to build by hand to generate the .msi. This is
>     not a big issue but for a collective effort it is better to have a
>     common way to build the binaries
> 2. some environment variables are not set and make ocaml crash (AFAIR, we
>     doesn't set OCAMLIB)
> 3. we don't ship the graphical toplevel
> 4. I am still not sure how to deal with ActiveTCL + OCaml (because of the
>     ActiveTCL license)
> 5. Total lack of documentation

Do you plan to support ocamlopt?  If yes, the users will have to install 
a toolchain (at least, an assembler+linker). Mingw has the advantage of 
producing binaries that depend only on msvcrt.dll (available on any 
fresh Windows installation), not on a specific version of 
msvcr80.dll/msvcr90.dll. But Windows users might prefer to install a 
version of VS Express or a Windows SDK.

Not building labltk seems ok. As for the graphical toplevel, I think 
there are some pending bugs (random crashes) with the current version 
under recent versions of Windows, so it's probably better not to include 
it. Some support for installing the emacs mode automatically and/or a 
version of ledit would be useful replacements.

-- Alain

Re: Pre-compiled ocaml binary for windows

[Sylvain Le Gall]

Hello,

On 07-12-2010, Alain Frisch <alain@frisch.fr> wrote:
> On 12/07/2010 01:24 AM, Sylvain Le Gall wrote:
>> Here is the list so far:
>> 1. no build system setup : Martin who first did the packaging, didn't
>>     have included how to build ocaml/findlib neither the binaries itself.
>>     So basically you need to build by hand to generate the .msi. This is
>>     not a big issue but for a collective effort it is better to have a
>>     common way to build the binaries
>> 2. some environment variables are not set and make ocaml crash (AFAIR, we
>>     doesn't set OCAMLIB)
>> 3. we don't ship the graphical toplevel
>> 4. I am still not sure how to deal with ActiveTCL + OCaml (because of the
>>     ActiveTCL license)
>> 5. Total lack of documentation
>
> Do you plan to support ocamlopt?  If yes, the users will have to install 
> a toolchain (at least, an assembler+linker). Mingw has the advantage of 
> producing binaries that depend only on msvcrt.dll (available on any 
> fresh Windows installation), not on a specific version of 
> msvcr80.dll/msvcr90.dll. But Windows users might prefer to install a 
> version of VS Express or a Windows SDK.

We will provide ocamlopt (32/64 bits). But indeed, the toolchain can be
an issue (esp. masm). I plan to use VS2008.

Maybe the native Lexifi's amd64/x86 backend is a better option. If we
are able to use this backend, we still have to use a linker ?

>
> Not building labltk seems ok. As for the graphical toplevel, I think 
> there are some pending bugs (random crashes) with the current version 
> under recent versions of Windows, so it's probably better not to include 
> it. Some support for installing the emacs mode automatically and/or a 
> version of ledit would be useful replacements.
>

I didn't known this fact. This is another reason for not building
labltk. Since I almost never use it, I don't think it will be a big
loose.

I will probably look for ledit (or lwt toplevel) which seems a better
alternative to emacs (too heavy too install).

Regards,
Sylvain Le Gall

Re: [Caml-list] Re: Pre-compiled ocaml binary for windows

[Alain Frisch]

On 12/07/2010 10:03 AM, Sylvain Le Gall wrote:
> We will provide ocamlopt (32/64 bits). But indeed, the toolchain can be
> an issue (esp. masm). I plan to use VS2008.

I don't think MASM is going to be an issue. FWIW, the Windows 7 SDK 
(which has nothing to do with Windows 7) contains everything needed 
(including the VS2008 C compiler, the assembler, the linker, the 
libraries, etc).

> Maybe the native Lexifi's amd64/x86 backend is a better option. If we
> are able to use this backend, we still have to use a linker ?

This native backend removes the need for an external assembler for using 
ocamlopt. Flexdll has a standalone mode to build DLLs which works fine 
to build pure OCaml .cmxs plugins for ocamlopt (there might be some 
issues when linking C libraries in the cmxs). But yes, to build the main 
program, you still need an external linker (this could be addressed by 
working more on flexdll) and also static runtime objects and libraries.

An option could be to ship a minimalistic main program, which simply 
dynlinks .cmxs files given on its command line.

>> Not building labltk seems ok. As for the graphical toplevel, I think
>> there are some pending bugs (random crashes) with the current version
>> under recent versions of Windows, so it's probably better not to include
>> it. Some support for installing the emacs mode automatically and/or a
>> version of ledit would be useful replacements.
>>
>
> I didn't known this fact. This is another reason for not building
> labltk. Since I almost never use it, I don't think it will be a big
> loose.

The graphical toplevel does not depend on labltk, so the two issues are 
really unrelated.  For crashes with the OCamlWin.exe, I was thinking 
about http://caml.inria.fr/mantis/view.php?id=4399 and 
http://caml.inria.fr/mantis/view.php?id=3052, but this might be pure 
FUD. The real problem is that nobody seems interested enough in this 
graphical toplevel to put serious work on it.


> I will probably look for ledit (or lwt toplevel) which seems a better
> alternative to emacs (too heavy too install).

If your hope is to make OCaml accessible to beginner hobbyists under 
Windows (I assume this is the primary audience for pre-compiled 
binaries), you might still want to provide easy ways to use code 
editors. Providing easy access only to the toplevel (be it graphical, or 
with a line-editor) might be a turnoff for beginners.


-- Alain

Re: Pre-compiled ocaml binary for windows

[Sylvain Le Gall]

On 07-12-2010, Alain Frisch <alain@frisch.fr> wrote:
> On 12/07/2010 10:03 AM, Sylvain Le Gall wrote:
>> We will provide ocamlopt (32/64 bits). But indeed, the toolchain can be
>> an issue (esp. masm). I plan to use VS2008.
>
> I don't think MASM is going to be an issue. FWIW, the Windows 7 SDK 
> (which has nothing to do with Windows 7) contains everything needed 
> (including the VS2008 C compiler, the assembler, the linker, the 
> libraries, etc).
>

Probably a good item for documentation/installation screen/link on the
future website of ocaml-installer.

>> Maybe the native Lexifi's amd64/x86 backend is a better option. If we
>> are able to use this backend, we still have to use a linker ?
>
> This native backend removes the need for an external assembler for using 
> ocamlopt. Flexdll has a standalone mode to build DLLs which works fine 
> to build pure OCaml .cmxs plugins for ocamlopt (there might be some 
> issues when linking C libraries in the cmxs). But yes, to build the main 
> program, you still need an external linker (this could be addressed by 
> working more on flexdll) and also static runtime objects and libraries.
>
> An option could be to ship a minimalistic main program, which simply 
> dynlinks .cmxs files given on its command line.
>

You mean like ld.ocaml:
https://forge.ocamlcore.org/projects/ld-ocaml/

>>> Not building labltk seems ok. As for the graphical toplevel, I think
>>> there are some pending bugs (random crashes) with the current version
>>> under recent versions of Windows, so it's probably better not to include
>>> it. Some support for installing the emacs mode automatically and/or a
>>> version of ledit would be useful replacements.
>>>
>>
>> I didn't known this fact. This is another reason for not building
>> labltk. Since I almost never use it, I don't think it will be a big
>> loose.
>
> The graphical toplevel does not depend on labltk, so the two issues are 
> really unrelated.  For crashes with the OCamlWin.exe, I was thinking 
> about http://caml.inria.fr/mantis/view.php?id=4399 and 
> http://caml.inria.fr/mantis/view.php?id=3052, but this might be pure 
> FUD. The real problem is that nobody seems interested enough in this 
> graphical toplevel to put serious work on it.
>

Thanks for the clarification. I didn't made a clear answer, but I know
that labltk and OCamlWin are 2 separate things. 

>
>> I will probably look for ledit (or lwt toplevel) which seems a better
>> alternative to emacs (too heavy too install).
>
> If your hope is to make OCaml accessible to beginner hobbyists under 
> Windows (I assume this is the primary audience for pre-compiled 
> binaries), you might still want to provide easy ways to use code 
> editors. Providing easy access only to the toplevel (be it graphical, or 
> with a line-editor) might be a turnoff for beginners.
>

You are right, in this case I will probably take into consideration this
project:
http://ocamleditor.forge.ocamlcore.org/

It has started on Windows ;-)

Regards,
Sylvain Le Gall

Re: [Caml-list] Re: Pre-compiled ocaml binary for windows

[gasche]

[-- Attachment #1: Type: text/plain, Size: 2405 bytes --]

On Tue, Dec 7, 2010 at 10:30 AM, Alain Frisch <alain@frisch.fr> wrote:

> The graphical toplevel does not depend on labltk, so the two issues are
> really unrelated.  For crashes with the OCamlWin.exe, I was thinking about
> http://caml.inria.fr/mantis/view.php?id=4399 and
> http://caml.inria.fr/mantis/view.php?id=3052, but this might be pure FUD.
> The real problem is that nobody seems interested enough in this graphical
> toplevel to put serious work on it.
>

I beg to differ. In my experience, the Graphics module is a wonderful tool
to get non-programming beginners interested in OCaml. I have been in the
position of teaching OCaml to beginners, and the single thing they remember
and found *fun* was displaying the mandelbrot fractal, and then playing with
different color functions to get fancy results.

I absolutely agree that Graphics is not the most important thing in OCaml,
and would be very happy to have a decent OCaml installer without it, but
still I think in a second time making it work would be well worth it.


 I will probably look for ledit (or lwt toplevel) which seems a better
>> alternative to emacs (too heavy too install).
>>
>
> If your hope is to make OCaml accessible to beginner hobbyists under
> Windows (I assume this is the primary audience for pre-compiled binaries),
> you might still want to provide easy ways to use code editors. Providing
> easy access only to the toplevel (be it graphical, or with a line-editor)
> might be a turnoff for beginners.


In most French "classes préparatoires", students learn programming by --
after a quick exposure to Maple, to be sure they don't risk learning too
much functional programming -- typing code directly in the toplevel.
Advanced software engineering there means "writing code in a notepad so that
the work isn't lost when the toplevel crashes". But it's not directly
relevant, as they still use Caml Light.

I agree that an Emacs integration would be useful, but maybe it could also
provide an ocaml-mode for one of the simpler, less powerful editors with
syntax highlighting and a shortcut to call the compiler. In GNU/Linux land,
those would be Gedit and Kate; I'm not sure what Windows people use now.
(There was also a discussion of Eclipse plugin, but I suspect this isn't
ready and would be a lot of work, so it's probably better to separate the
two efforts)

[-- Attachment #2: Type: text/html, Size: 3627 bytes --]

Re: [Caml-list] Re: Pre-compiled ocaml binary for windows

[Alain Frisch]

On 12/07/2010 10:42 AM, Sylvain Le Gall wrote:
>> An option could be to ship a minimalistic main program, which simply
>> dynlinks .cmxs files given on its command line.
>>
>
> You mean like ld.ocaml:
> https://forge.ocamlcore.org/projects/ld-ocaml/

Or just something like:

let () =
    try
      for i = 1 to Array.length Sys.argv - 1 do
        Dynlink.loadfile Sys.argv.(i)
      done
    with exn ->
      Format.eprintf "Uncaught exception: %s@." (Printexc.to_string exn)

(untested, and you probably want to print the stack trace as well)


-- Alain

Re: [Caml-list] Re: Pre-compiled ocaml binary for windows

[Alain Frisch]

On 12/07/2010 10:42 AM, gasche wrote:
> On Tue, Dec 7, 2010 at 10:30 AM, Alain Frisch <alain@frisch.fr
> <mailto:alain@frisch.fr>> wrote:
>
>     The graphical toplevel does not depend on labltk, so the two issues
>     are really unrelated.  For crashes with the OCamlWin.exe, I was
>     thinking about http://caml.inria.fr/mantis/view.php?id=4399 and
>     http://caml.inria.fr/mantis/view.php?id=3052, but this might be pure
>     FUD. The real problem is that nobody seems interested enough in this
>     graphical toplevel to put serious work on it.
>
>
> I beg to differ. In my experience, the Graphics module is a wonderful
> tool to get non-programming beginners interested in OCaml. I have been
> in the position of teaching OCaml to beginners, and the single thing
> they remember and found *fun* was displaying the mandelbrot fractal, and
> then playing with different color functions to get fancy results.

We were discussing the graphical toplevel (OCamlWin.exe), not the 
Graphics module. The two are unrelated.


-- Alain

Re: [Caml-list] Re: Pre-compiled ocaml binary for windows

[gasche]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

On Tue, Dec 7, 2010 at 10:52 AM, Alain Frisch <alain@frisch.fr> wrote:
>
> We were discussing the graphical toplevel (OCamlWin.exe), not the Graphics
> module. The two are unrelated.


I assumed you meant the graphics-enabled command-line toplevel "ocamlgraph".
It's fine then, as CamlWin is buggy and difficult to use.

[-- Attachment #2: Type: text/html, Size: 584 bytes --]

Re: [Caml-list] Pre-compiled ocaml binary for windows

[ygrek]

On Mon, 6 Dec 2010 16:28:41 +0100
Damien Doligez <damien.doligez@inria.fr> wrote:

> It depends on which port you want.  For Cygwin, there is an up-to-date
> cygwin package.  For the other ports, we are looking for volunteers to
> compile and publish the binaries.

FWIW, I've setup hudson CI build server for some of the ocaml software.
There are binary builds of svn trunk and version/3.12 for 32-bit mingw.
See http://build.ygrek.org.ua/hudson/job/ocaml-3.12.x/label=qemu-i386-win2k/lastSuccessfulBuild/
trunk is not available currently because of ftbfs.
I am planning to have msvc build and 64-bit slave some day.

-- 
 ygrek
 http://ygrek.org.ua

Re: [Caml-list] Re: Pre-compiled ocaml binary for windows

[Mauricio Fernandez]

On Tue, Dec 07, 2010 at 10:49:14AM +0100, Alain Frisch wrote:
> On 12/07/2010 10:42 AM, Sylvain Le Gall wrote:
>>> An option could be to ship a minimalistic main program, which simply
>>> dynlinks .cmxs files given on its command line.
>>>
>>
>> You mean like ld.ocaml:
>> https://forge.ocamlcore.org/projects/ld-ocaml/
>
> Or just something like:
>
> let () =
>    try
>      for i = 1 to Array.length Sys.argv - 1 do
>        Dynlink.loadfile Sys.argv.(i)
>      done
>    with exn ->
>      Format.eprintf "Uncaught exception: %s@." (Printexc.to_string exn)
>
> (untested, and you probably want to print the stack trace as well)

This approach is not exactly convenient because the list of cmxs to be loaded
can easily get very long...

ld.ocaml does a little more than that: it first builds a catalog of available
cmxs and then tries to satisfy the dependencies from the "root" cmxs, both in
terms of imported interfaces and implementations. It thus allows multiple
library versions to coexist, since it operates with signature digests instead
of filenames. This is similar to (C) library sonames, but safer because
signature digests are intrinsically so.

There are other subtleties to building the dynamic loader: it has to contain
the libs it's linked against in full and has to avoid duplicated module
loading by tracking which modules are already available.

ld.ocaml uses GNU BFD to extract the cmxs header, so it should only need
minor tweaks (essentially in the build system) to work on Windows.

-- 
Mauricio Fernandez  -   http://eigenclass.org

Re: [Caml-list] Re: Pre-compiled ocaml binary for windows

[Alain Frisch]

On 12/09/2010 12:54 PM, Mauricio Fernandez wrote:
> This approach is not exactly convenient because the list of cmxs to be loaded
> can easily get very long...

I was thinking of replacing the call to "ocamlopt" used to build the 
main program (which requires external tools) with a call to "ocamlopt 
-shared" to build a single monolithic .cmxs file that contains all the 
modules for the program. So the generic loader would usually be called 
with a single argument (and it would probably be better to leave the 
other arguments so that they can be used by the program, as for "ocamlrun").

-- Alain