2008/10/14, Sylvain Le Gall <sylvain@le-gall.net>:
> On 14-10-2008, Adrien <camaradetux@gmail.com> wrote:
>> 2008/10/14, Daniel Bünzli <daniel.buenzli@erratique.ch>:
>>>
>>> Le 14 oct. 08 à 09:59, David Allsopp a écrit :
>>>
>>>> Can I ask what the motivation is for this (out of interest, not
>>>> criticism)?
>>>
>>> Maybe because if you want to distribute executables using cygwin you
>>> have to release your code under a GPL compatible license [1].
>>>
>>> Daniel
>>>
>>> [1] http://caml.inria.fr/pub/distrib/ocaml-3.10/notes/README.win32
>>
>> I would give another explanation : cygwin is big and slow.
>> A base cygwin install is at least 1GB (when fully configured, after
>> carefully reviewing *each* package), a regular one is 2GB. XP itself
>> is not that big, I've not seen many applications that big, only CAD
>> ones.
>> Cygwin is also slow, though it will probably not impact a student use
>> (networking is slower due to the translation, I have mldonkey in
>> mind). ./configure are also painfully slow, the need to run several
>> small commands where startup time is more important than runtime gives
>> cygwin no chance [1].
>>
>> On the other hand, mingw on its own is about 80MB. If you add a few
>> things, it will weight at most 200MB which is 10 times smaller than
>> the cygwin solution.
>>
>
> Welcome in the windows world. For your information, there is a lot of
> thing in windows that is bigger than cygwin.
>
> Just taking a fresh example (install it last sunday): PSDK for AMD64
> (platform SDK). This is the recommanded C compiler to compile OCaml for
> Win64. It takes 935MB (ok this is not 1GB). It is just what is replacing
> mingw !!!!
>
> Other examples:
> - games
> - Microsoft Visual Studio 2005 Team, takes ~6GB (official number from
>   microsoft website)
>
> If hard disk space were a problem, nobody would install Microsoft
> products...

Unreal Tournament 2004 takes 5.3GB, I have it installed on an XFS
partition though. ;)
It's just games, not games on a microsoft platform (PS3 and Blu-Ray anyone ?).
But I dont think you will get many students install a 2GB environment.
If they have too, they will of course but they are likely to prefer
the 200MB one. And the point is not students, cross-compilation  will
simply give better results with less troubles.

> Another information, I have various benchmark on cygwin. My conclusion
> was not what i have expected. Most of the time cygwin runtime has a good
> speed. This is not so slow in fact. I think most of the slowness you can
> see is because you are working in a MSDOS/emulated X terminal which
> seems slow (but is not, this is just a question of refresh rate).
> Seriously, cygwin is not that bad. I would still not recommend using it
> for various other reasons.

Indeed, runtime has no reason to be affected as long as it's not using
external libraries, typically -lws2_32, winsock2). The point is really
startup.
As for terminal slowness, my computer boots in 16 seconds under linux.
I recompiled my kernel yesterday and activated PRINTK_TIME/Show timing
information on printks, it gives you the time a kernel message was
emitted, related to startup. At the end of the boot, the kernel was
giving times 3 seconds better than an independent chronometer. There
had been enough things to write on the console for message to take 3
seconds to be displayed. Displaying on a terminal is slooow
everywhere, not just windows.

Also, I don't think cygwin is bad. I just think it is not the
appropriate answer for most of us. IMHO msys/mingw is a better
*approach*, however their shell implementation is bastard. They
decided to support both forward and backward slashes for instance,
this has the awful consequence of giving you "not found" errors when
using /c/gnu/msys/home/Adrien/icu\\source (personal experience). That
is however something at the msys level, not the mingw one.


 ---

Adrien Nader

>
> Regards
> Sylvain Le Gall
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>