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 pBFA3ll4012390 for ; Thu, 15 Dec 2011 11:03:47 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgBAPbE6U5KfVM2kGdsb2JhbABEqyQIIgEBAQEJCQ0HFAQhgXIBAQEEEgIsARsUCQEDDAYFCw0uIQEBEQEFAQ4BDQYTIqJUCotlgmuEbkCIcQIFC4t8BI09hzmKbIMJPYN5 X-IronPort-AV: E=Sophos;i="4.71,356,1320620400"; d="scan'208";a="123462579" Received: from mail-ee0-f54.google.com ([74.125.83.54]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 15 Dec 2011 11:03:41 +0100 Received: by eekc50 with SMTP id c50so2471971eek.27 for ; Thu, 15 Dec 2011 02:03:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a2uFrUefrw8E3AMCxoh5V4h1wF9L1/AjfJPPM3p8N9s=; b=LdZpQmNVxOD7ZSbBu76jy0jf15s1BTvqsfoYGREJzfZBmU+xmvPMaXON/Exp1bpJmA zhDmqPWhCGlWw0EmYuD/yIt/ZESdv9kLLftoSzH+3MtOVtrmAZdIcBiU0WI2TxJEfRyn aB6nGaxpDuRxOdbyOhwSJ7u0B1Zie1B2T4hnM= MIME-Version: 1.0 Received: by 10.213.31.147 with SMTP id y19mr295209ebc.80.1323943421507; Thu, 15 Dec 2011 02:03:41 -0800 (PST) Received: by 10.213.10.148 with HTTP; Thu, 15 Dec 2011 02:03:39 -0800 (PST) In-Reply-To: References: <4EDE33A0.6070004@gmail.com> <1323760512.9833.9.camel@samsung> <4EE711FB.5020602@frisch.fr> <4EE83C26.7090108@frisch.fr> <1323867161.7750.27.camel@samsung> Date: Thu, 15 Dec 2011 11:03:39 +0100 Message-ID: From: Adrien To: Martin DeMello Cc: Gerd Stolpmann , Alain Frisch , Jonathan Protzenko , caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Some comments on recent discussions On 15/12/2011, Martin DeMello wrote: > On Wed, Dec 14, 2011 at 4:52 AM, Gerd Stolpmann > wrote: >> >> 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. > > does mingw+msys not already do this? the last time i checked, it > shipped with rxvt, bash and bunch of natively compiled standard posix > utilities. It doesn't ship with much actually. sh.exe and a few things but it doesn't even have coreutils by default iirc. The usual way to setup an environment was to download every component from sourceforge.net, one by one and by trial and error until you had everything. Nowadays you can use mingw-get to download packages more easily. It's endorsed (and created) by mingw.org. It doesn't support uninstallation though and I find that many things on mingw.org are of dubious quality. That being said, msys causes problems of its own. It's a bit between Cygwin and Windows, with Cygwin already being between Windows and Unix. You quite often end up with bastard mixes between unix and windows (mostly paths: I once ended up writing a backward slash as \\\\\\\\\\\\\\\\ I think). You typically don't know where you are with msys: it really blurs the line between the unix/posix and the windows worlds. Also, note that msys works like cygwin: you have a number of msys applications which use some DLL. Unlike cygwin however, you're strongly advised not ever remotely try to make your application an msys one. Btw, msys has to be built with a gcc-2.9[56] fork since it uses a target that has never been upstreamed. It's smaller than cygwin but it's not really prettier unfortunately. Regards, Adrien Nader