[erlang-questions] Windows

[zxq9]

On 2015年5月20日 水曜日 10:30:52 Dan Gudmundsson wrote:
> Does not cygwin still produce executables that depend on cygwin.dll, i.e.
> non native windows programs
> that will not work if you do not have cygwin (I know you can crosscompile
> with mingw compilers but that does not make
> it easier).
> 
> I have ditched cygwin since long ago, and I prefer mingw and msys, it works
> and you can use Microsoft compiler or mingw compilers.
> rebar works and even erlang.mk worked as far as I tried it.
> 
> IMO cygwin is a rabbit hole, do not go there it just makes it worse.

I think there are three categories where cygwin works:

1. You are providing a platform, so you can statically compile certain things and include the necessary cygwin elements with your platform (have the installer do it -- cygwin's own installer was even developed in a way that makes creating your own environment installer based on it easyish). It seems that this is the case with Erlang Solution's own installer package (the mingw build process for Erlang appears to still be black magic, unless that has changed since I last checked).

2. You are developing for yourself and for whatever reason the overhead of maintaining a cygwin environment seems like a good tradeoff compared to just running a different OS either natively or within a VM.

3. You have a paid support structure that takes care of the cygwin stuff for you.

All of the above cases are developer or server-side situations. As far as "average Windows user, client-side target audience" type things go, mingw is so vastly superior that it is difficult to even imagine a point of comparison: one builds programs that can work within a Unixy environment on Windows, and the other builds actual Windows programs.

I did not address MS's Visual Foo environments because including a compiler with an installation in a separate installer isn't straightforward as licenses go, so I have no experience in that area, but assuming the proper money changes hands and rituals attended I can only imagine that the result would be *very* much like mingw, and very unlike cygwin.

Once again, though, Erlang is used almost exclusively on the server-side, so it may not be unreasonable to accept some level of administrative overhead to maintain an environment -- especially since it *is* possible to distribute cygwin-built binaries, just not very straightforward compared to real windows binaries. In addition, while this or that Erlang release-building tool may or may not take certain Unix utilities for granted, the built-in utilites (which very few use) do not. If there is no C code involved, rebar tends to work on Windows -- but a tool based on gnu make won't. That's an issue with the tool, not Erlang, its runtime, or anything else in the core distribution.

Perhaps that is a big part of the problem here. Most server development for web/game/chat/mobile app backends target Linux, not Windows. Quite a lot of client-side software targets Windows, Linux and OSX all at once as a matter of course (if not mobile platforms as well). The expectations are radically different between the two development cases. So when one says "we need to support Foo OS development environments better" you really have to include "... in the context of [client || server || wev] development" or the statement is meaningless.

Erlang doesn't support developing client software very well at all and Windows just happens to get pinched in the crossfire there, with client software being its most common case. Its not just a Windows problem, Erlang is a challenging environment within which to develop Linux, BSD and OSX client software as well. The focus on server-side and tiny-service-device releases skews the entire community's approach to development toward server code, not client code.

-Craig