From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pBEEOutl002905 for ; Wed, 14 Dec 2011 15:24:56 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUCAB2x6E7RVaE2kGdsb2JhbABDmnCIGQGFAoEpgWoIIgEBAQEJCQ0HFAQhgXIBAQEDARICLAEbEgIJAQMBCwYFCw0NISEBAREBBQEKBAENBhMICgkHh1gImgwKi2SCa4UfQIhxAgULg26IEASCWJIcimyDCT2DeQ X-IronPort-AV: E=Sophos;i="4.71,352,1320620400"; d="scan'208";a="135391818" Received: from mail-fx0-f54.google.com ([209.85.161.54]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 14 Dec 2011 15:24:50 +0100 Received: by faaf16 with SMTP id f16so2131249faa.27 for ; Wed, 14 Dec 2011 06:24:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7bFAzCLo6S2/dpyw+ktZ/1bQ2vFTKY/0qJ1JrtP1jCU=; b=EPsEIV3GeMGdd7Ok9RdmirvnX8XGF27UCAd7pQS223EwdjF5tf/mtWHrAdxiwxj4Cx ygH3ncmC9FheHVLiDqwtBluRRHkSXDRMiusEIi0qeCl7T6jecrZjHH31cc2DDRfYh7yC SUuRCB42ZVf+1RZTFEf/VT2zk8bDBY/FwF1tg= Received: by 10.180.98.138 with SMTP id ei10mr5203988wib.52.1323872690220; Wed, 14 Dec 2011 06:24:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.43.4 with HTTP; Wed, 14 Dec 2011 06:24:29 -0800 (PST) In-Reply-To: References: <4EDE33A0.6070004@gmail.com> <1323760512.9833.9.camel@samsung> <4EE711FB.5020602@frisch.fr> <4EE83C26.7090108@frisch.fr> <4EE86D90.6080409@gmail.com> <4EE87976.4030604@frisch.fr> From: Gabriel Scherer Date: Wed, 14 Dec 2011 15:24:29 +0100 Message-ID: To: Adrien Cc: Alain Frisch , Jonathan Protzenko , Martin DeMello , Gerd Stolpmann , caml-list@inria.fr Content-Type: multipart/alternative; boundary=f46d044267fe6dadcc04b40e216d Subject: Re: [Caml-list] Some comments on recent discussions --f46d044267fe6dadcc04b40e216d Content-Type: text/plain; charset=ISO-8859-1 > > As for the build systems, I'd advise everyone to use OASIS instead of > custom > systems: it's not perfect on windows but for cairo2 and archimedes, I think > I only had to change paths from backward-slashes to forward-slashes in > setup.data (or the other way round) (took 15 seconds). > A clarification: oasis is not in itself a build system; it provides a common interface to build, configure and install packages, as well as metadata (documentation, etc.), but it delegates building to real build system; by default, it uses ocamlbuild, but it is very easy to plug just any build system (make, omake, ocp-build...) using the "Custom" commands: http://oasis.forge.ocamlcore.org/MANUAL.html#plugin-custom-doc-conf-test-install-build In this case, of course, the underlying system can become an obstacle to portability (to windows or for example BSD when you use gnuisms in your build scripts). On Wed, Dec 14, 2011 at 2:37 PM, Adrien wrote: > On 14/12/2011, Alain Frisch wrote: > > On 12/13/2011 10:53 AM, Adrien wrote: > >> On 13/12/2011, Alain Frisch wrote: > >>> As Xavier said, it would be great to find someone who'd like to join > the > >>> core dev team in order to improve support for Windows. Anyone > interested? > >> > >> In my experience, OCaml is working mostly fine on Windows. I can see > >> some issues but nothing huge. Do you have some examples? > > > > It is very good to hear about some successful experiences with OCaml > > under Windows! > > > > Needless to say, but at LexiFi we are also very happy with OCaml under > > Windows. > > > > > > That said, the situation probably needs to be improved in order to > > attract a larger audience. Many users complain about not being able to > > install and use OCaml under Windows in reasonable amount of time. And > > the binary packages for Windows tend to lack behind official releases of > > OCaml. > > As far as I'm concerned, I managed to do it in a few hours last summer > (less > than a morning) but: I'm used to digging in the system (cygwin, msys, > slackware) and packaging (godi, slackware, yypkg), and I've been lucky to > have to use libraries that used oasis. That's quite a lot of conditions for > most cases but, still, it's usually not terribly difficult. > > I'd also like to mention the #ocaml IRC channel of freenode: IRC is a good > communication medium for such things imho. > > > As a concrete problem, until a few days ago, the mingw port could not be > > used with recent versions of Cygwin without some small hacks (like > > copying manually /bin/gcc-3.exe into gcc.exe, and passing more > > directories to flexlink). No big deal, but it can discourage beginners. > > Actually, I think that you should have used the "/etc/alternatives" > symlinks: /usr/bin/gcc points to /etc/alternatives/FOO and you can make > this > FOO symlink point to the /usr/bin/BAR binary that you want. > > I've never considered /etc/alternatives to be a good solution however > (feels > like spaghetti code). > > > A more serious issue is the lack of support for ocamlfind, GODI, and > > many libraries around for Windows. Also, ocamlbuild does not play very > > nicely with Windows. A related point: the assumption is generally made > > that OCaml developpers under Windows need to have a running Cygwin > > installation. This is a huge barrier to entry. It would take some time > > to address this, but there is really no reason why ocamlbuild, for > > instance, should rely on an external Unix-like shell > > (I believe the only reason today is to rely on bash for quoting > > arguments!). And it is not difficult to adapt the build system for most > > libraries to avoid any dependency on Unix-like tools (using either > > ocamlbuild or omake). It just takes time to do so (and to maintain the > > result). > > Last time I had to setup an ocaml install of windows, I pondered trying to > remove the dependency on bash or at least make it sh. I think that apart > from that, it was possible to use ocamlbuild inside cmd.exe directly. > > As for the build systems, I'd advise everyone to use OASIS instead of > custom > systems: it's not perfect on windows but for cairo2 and archimedes, I think > I only had to change paths from backward-slashes to forward-slashes in > setup.data (or the other way round) (took 15 seconds). > > > For the native compiler, we need an external toolchain, but this is not > > a huge issue. With some little amount of work, one could support a > > standalone msys/mingw (as opposed to mingw compilers packaged in > > Cygwin), and it would be interesting to come up with a minimal mingw > > distribution (only with a C compiler, assembler, etc, as required by > > ocamlopt) that could be packaged together with OCaml. On the MSVC side, > > everything needed for the MSVC port (C compiler, linker, assembler, > > supporting headers and libraries) is found in a single free download > > from Microsoft. > > I've never really liked bundles or SDKs. They tend to be big, incompatible > with others and almost impossible to upgrade. > That's the reason I've started yypkg and while it has been mostly dormant > for almost a year, I will be able to spend a notable amount of time on it > and on the packages for it in a few weeks. > > That reminds me that the mingw-w64 team has created a tool named "gendef" > to > enable the use of gcc-compiled libraries with msvc. > > > I can also mention that with some work, one could come up with a > > standalone version of ocamlopt that does not require any external tool > > to produce .cmxs plugins (we have done that at LexiFi, by replacing the > > assembler code emitter with a direct binary code generator; and by > > extending flexdll to produce dlls without an external linker). Getting > > rid of the external toolchain to produce standalone programs is more > > difficult: to create the .exe, one needs some libraries and object > > files; a solution could be to do the same as for bytecode, that is, > > having a generic driver which loads user code concatenated to it. But > > being able to generate .cmxs without any external tool already make it > > possible to distribute OCaml native applications (packaged with > > ocamlopt) that the users can extend with OCaml plugins. > > I don't think it would be possible to live without a C toolchain simply > because we use C libraries all the time. It would be useful it it were > easier than getting C libraries but a tool like yypkg (or anything else) > is a closer goal with broader benefits. > > I'm quite interested in the ability to create .cmxs files without a C > compiler and can already picture me using it. I've also noticed Benedikt's > ocamlnat work. Would it be usable to script native-code applications? > Maybe with less requirements? > > > > I guess most > >> of the work would be to move forward instead of being stuck in the > >> current situation. > > > > Can you elaborate? What are the most important issues in the current > > situation? > > I haven't been completely clear: I think the current situation is mostly > fine but I fear that it doesn't evolve anymore and doesn't react to changes > on windows or doesn't get some improvements that would be unixy-only. > > Regards, > Adrien Nader > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > > --f46d044267fe6dadcc04b40e216d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As for the build systems,= I'd advise everyone to use OASIS instead of custom
systems: it's not perfect on windows but for cairo2 and archimedes, I t= hink
I only had to change paths from backward-slashes to forward-slashes in
setup.data (or the other way round) (took 15 seconds).

A clarification: oasis is not in itself a build system; it provides a c= ommon interface to build, configure and install packages, as well as metada= ta (documentation, etc.), but it delegates building to real build system; b= y default, it uses ocamlbuild, but it is very easy to plug just any build s= ystem (make, omake, ocp-build...) using the "Custom" commands:
=A0 http://oasis.forge.ocamlcore.org/MANUAL.html#pl= ugin-custom-doc-conf-test-install-build

In this case, of course,= the underlying system can become an obstacle to portability (to windows or= for example BSD when you use gnuisms in your build scripts).

On Wed, Dec 14, 2011 at 2:37 PM, Adrien <camaradetux@gmai= l.com> wrote:
On 14/12/2011, Alain Frisch <alain@frisch.fr> wrote:
> On 12/13/2011 10:53 AM, Adrien wrote:
>> On 13/12/2011, Alain Frisch<= alain@frisch.fr> =A0wrote:
>>> As Xavier said, it would be great to find someone who'd li= ke to join the
>>> core dev team in order to improve support for Windows. Anyone = interested?
>>
>> In my experience, OCaml is working mostly fine on Windows. I can s= ee
>> some issues but nothing huge. Do you have some examples?
>
> It is very good to hear about some successful experiences with OCaml > under Windows!
>
> Needless to say, but at LexiFi we are also very happy with OCaml under=
> Windows.
>
>
> That said, the situation probably needs to be improved in order to
> attract a larger audience. Many users complain about not being able to=
> install and use OCaml under Windows in reasonable amount of time. =A0A= nd
> the binary packages for Windows tend to lack behind official releases = of
> OCaml.

As far as I'm concerned, I managed to do it in a few hours last s= ummer (less
than a morning) but: I'm used to digging in the system (cygwin, msys, slackware) and packaging (godi, slackware, yypkg), and I've been lucky = to
have to use libraries that used oasis. That's quite a lot of conditions= for
most cases but, still, it's usually not terribly difficult.

I'd also like to mention the #ocaml IRC channel of freenode: IRC is a g= ood
communication medium for such things imho.

> As a concrete problem, until a few days ago, the mingw port could not = be
> used with recent versions of Cygwin without some small hacks (like
> copying manually /bin/gcc-3.exe into gcc.exe, and passing more
> directories to flexlink). =A0No big deal, but it can discourage beginn= ers.

Actually, I think that you should have used the "/etc/alternativ= es"
symlinks: /usr/bin/gcc points to /etc/alternatives/FOO and you can make thi= s
FOO symlink point to the /usr/bin/BAR binary that you want.

I've never considered /etc/alternatives to be a good solution however (= feels
like spaghetti code).

> A more serious issue is the lack of support for ocamlfind, GODI, and > many libraries around for Windows. =A0Also, ocamlbuild does not play v= ery
> nicely with Windows. A related point: the assumption is generally made=
> that OCaml developpers under Windows need to have a running Cygwin
> installation. This is a huge barrier to entry. It would take some time=
> to address this, but there is really no reason why ocamlbuild, for
> instance, should rely on an external Unix-like shell
> (I believe the only reason today is to rely on bash for quoting
> arguments!). =A0And it is not difficult to adapt the build system for = most
> libraries to avoid any dependency on Unix-like tools (using either
> ocamlbuild or omake). It just takes time to do so (and to maintain the=
> result).

Last time I had to setup an ocaml install of windows, I pondered tryi= ng to
remove the dependency on bash or at least make it sh. I think that apart
from that, it was possible to use ocamlbuild inside cmd.exe directly.

As for the build systems, I'd advise everyone to use OASIS instead of c= ustom
systems: it's not perfect on windows but for cairo2 and archimedes, I t= hink
I only had to change paths from backward-slashes to forward-slashes in
setup.data (or the other way round) (took 15 seconds).

> For the native compiler, we need an external toolchain, but this is no= t
> a huge issue. =A0With some little amount of work, one could support a<= br> > standalone msys/mingw (as opposed to mingw compilers packaged in
> Cygwin), and it would be interesting to come up with a minimal m= ingw
> distribution (only with a C compiler, assembler, etc= , as required by
> ocamlopt) that could be packaged together with= OCaml. On the MSVC side,
> everything needed for the MSVC port (C compiler, linker, assembler,
> supporting headers and libraries) is found in a single free download > from Microsoft.

I've never really liked bundles or SDKs. They tend to be big, inc= ompatible
with others and almost impossible to upgrade.
That's the reason I've started yypkg and while it has been mostly d= ormant
for almost a year, I will be able to spend a notable amount of time on it and on the packages for it in a few weeks.

That reminds me that the mingw-w64 team has created a tool named "gend= ef" to
enable the use of gcc-compiled libraries with msvc.

> I can also mention that with some work, one could come up with a
> standalone version of ocamlopt that does not require any external tool=
> to produce .cmxs plugins =A0(we have done that at LexiFi, by replacing= the
> assembler code emitter with a direct binary code generator; and by
> extending flexdll to produce dlls without an external linker). =A0Gett= ing
> rid of the external toolchain to produce standalone programs is more > difficult: to create the .exe, one needs some libraries and object
> files; a solution could be to do the same as for bytecode, that is,
> having a generic driver which loads user code concatenated to it. But<= br> > being able to generate .cmxs without any external tool already make it=
> possible to distribute OCaml native applications (packaged with
> ocamlopt) that the users can extend with OCaml plugins.

I don't think it would be possible to live without a C toolchain = simply
because we use C libraries all the time. It would be useful it it were
easier than getting C libraries but a tool like yypkg (or anything else)
is a closer goal with broader benefits.

I'm quite interested in the ability to create .cmxs files without a C compiler and can already picture me using it. I've also noticed Benedik= t's
ocamlnat work. Would it be usable to script native-code applications?
Maybe with less requirements?

> =A0> I guess most
>> of the work would be to move forward instead of being stuck in the=
>> current situation.
>
> Can you elaborate? =A0What are the most important issues in the curren= t
> situation?

I haven't been completely clear: I think the current situation is= mostly
fine but I fear that it doesn't evolve anymore and doesn't react to= changes
on windows or doesn't get some improvements that would be unixy-only.
Regards,
Adrien Nader

--
Caml-list mailing list. =A0Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


--f46d044267fe6dadcc04b40e216d--