From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pBECqsF9031261 for ; Wed, 14 Dec 2011 13:52:54 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMBAGGb6E7U4367kGdsb2JhbABDhQikLYFxIgEBAQEJCQ0HFAMigXIBAQQBI00JBQsLGAICJgICSQENBhMbh18CpSGSCYEvgkqGeoEWBI0OjTOMXg X-IronPort-AV: E=Sophos;i="4.71,352,1320620400"; d="scan'208";a="123335142" Received: from moutng.kundenserver.de ([212.227.126.187]) by mail4-smtp-sop.national.inria.fr with ESMTP; 14 Dec 2011 13:52:49 +0100 Received: from office1.lan.sumadev.de (dslb-188-097-012-119.pools.arcor-ip.net [188.97.12.119]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LwXB1-1QfHML2xsF-018JUq; Wed, 14 Dec 2011 13:52:42 +0100 Received: from [192.168.178.11] (546BF816.cm-12-4d.dynamic.ziggo.nl [84.107.248.22]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 38EEFC00C7; Wed, 14 Dec 2011 13:52:42 +0100 (CET) From: Gerd Stolpmann To: Alain Frisch Cc: Adrien , Martin DeMello , Gerd Stolpmann , Jonathan Protzenko , caml-list@inria.fr In-Reply-To: <4EE83C26.7090108@frisch.fr> References: <4EDE33A0.6070004@gmail.com> <1323760512.9833.9.camel@samsung> <4EE711FB.5020602@frisch.fr> <4EE83C26.7090108@frisch.fr> Content-Type: text/plain; charset="UTF-8" Date: Wed, 14 Dec 2011 13:52:41 +0100 Message-ID: <1323867161.7750.27.camel@samsung> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:Hb4t87RAfwJQ6Fdsn3+T7ecJJ8jELzrTGVldbLAnddc LU1beuZVoTZUYQgFXofECIPlhLXTEIf1/5OaMYmkshTOayuEAQ N0JL8E80bU7I7Oaoq++/h73Lz5zQ1/B9SogrE9OGQEyxDTOjmB dxVAlR9pCADtKW4gdhRJniK9BelozT2IUDGWi+zgo8ZFcZDzmJ f1Zfx8SRpUJIu3pv3vd3DT56xgcrosxLo7hQIt30pdQza8p3vV vUjWrdmGi1j+k0cdmfnrsZpAIhHEomdU34GvRzKCNWr5mvkGBc pjOXFi24XUl8QqrYhH5gF5o6goEQv5I5kjYkiBlNzwaHVakbI0 g50KkYyHdQdbcJkpPyluDgnZiDiwg54Cs7CbJRDO4 Subject: Re: [Caml-list] Some comments on recent discussions Am Mittwoch, den 14.12.2011, 07:03 +0100 schrieb Alain Frisch: > 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 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. > > 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). I don't think you will be able to convince everybody - at this point the issue becomes political in some sense: Do we want to give up our Unix habits just to support an OS we (often enough) do not like, and would only cover to get more love from the world? There could be an alternative: The "busybox approach". We could develop a toolkit that covers all the Unix commands we need for the existing build scripts. It would include easy things like cp, mv etc., but also a classic "make" (medium difficulty, note that it could reuse the godi_make code), and especially a POSIX shell. The latter is a bit of work, but not too much. I'd guess the overall effort takes not more than 1-2 weeks if done by somebody how knows the semantics of the tools very well. There are a number of advantages over Cygwin: - No danger of running into licensing problems - The Unix compatibility is only maintained for commands, but not on the system call level (eaiser to use, less surprises, fewer deps,...) - It would only be a small download, and easy to integrate into installers Gerd > 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 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 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? > > > Alain >