Re: [Caml-list] Some comments on recent discussions

[Adrien <camaradetux@gmail.com>]

On 15/12/2011, Martin DeMello <martindemello@gmail.com> wrote:
> On Wed, Dec 14, 2011 at 4:52 AM, Gerd Stolpmann <info@gerd-stolpmann.de>
> 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