Re : Re : Re: [Caml-list] Re: MinGW port w/o Cygwin?

[Adrien <camaradetux@gmail.com>]

2007/12/26, Kuba Ober <ober.14@osu.edu>:
> On Sunday 23 December 2007, Adrien wrote:
> > 2007/12/20, Kuba Ober <ober.14@osu.edu>:
> > > I guess that Ocaml maintainers should just drop that Cygwin requirement,
> > > and tweak their build process to work "out of the box" with MSYS/MinGW.
> >
> > You shouldn't see cygwin as a _requirement_.
> > Ocaml installation from source (let the binary distributions be a
> > special case) use C. If there is no c compiler installed as it is
> > under all windows installations (I mean right after setup is
> > completed) ocaml simply can't be installed ; the problem is not with
> > ocaml or cygwin but with windows. Cygwin is not a fancy requirement
> > just one of the few ways to get a c compiler under windows.
> >
> > Also mingw without cygwin still lacks a lot of things. Capabilities
> > are there but it seems header files have not been updated in ages and
> > linker flags need to be different (you will often need -lws2_32 for
> > many C apps especially).
>
> THe right way is to update mingw headers, submit to the maintainers, and go
> from there. That's the OSS way.

I know, I only lack of time to do this properly and I've been
astonished to see some headers were older than Internet Explorer 5.5
(or even 5) !
It seemed to be the dev just didn't feel like updating the headers so
it would take me some time to convince them with a nice and polished
patch.


> > Anyway, the result is a big headache for the developper. I perfectly
> > understand the ocaml team is not willing to make a complete mingw/msys
> > port ; it's such a mess.
>
> It's the only sane way to go. THere's no technical reason to require a unix
> environment to build ocaml. Big applications build on Windows just fine...

Ocaml doesn't rely on an unix environment. It makes use of it when
available though. How could you run a configure script on windows
without msys|mingw|cygwin ? [btw the result is incorrect on msys/mingw
so don't use] The only solutions are else proprietary non-microsoft
shells running only under windows with specific scripting languages or
a proprietary microsoft shell running only under windows with a
specific scripting language.

If you consider python (or perl iirc, or even tcl/tk), the same rule
apply and compiling from source under windows is not advised. OCaml on
the other hand 1-works and 2-works even on unsupported toolchains. I
too would love something better but I think we can't really complain.

> > So there would be msvc, cygwin, cygwin/mingw, msys/mingw with
> > different configuration files for each. While such a port would be
> > easy to create it wouldn't be wise to create it imho ; it wouldn't
> > help maintaining and would create bugs along with more work for the
> > ocaml team.
> Supporting Cygwin at all is a waste IMHO. Either you run Unix or Windows,
> choose one and stick with it...
>

Cygwin works and is commercially supported. Porting efforts are also
less important than for msys ; I would say porting from unix to cygwin
is easier than porting from cygwin to windows.


> > And then one could add a SFU port (Services For Unix) which lets you
> > compile ocaml without problem except that it works so well ocaml
> > thinks it is running under unix and uses forward-slashes as path
> > separators. (everything that ./configure can enable is enabled)
>
> IIRC Windows accepts forward slashes everywhere just fine.

I just checked and that's true. The problem was maybe with "/c/"
(mingw) or "/dev/fs/C:/" (sfu) instead of windows's "c:". I'll have to
check.


> > compile with mingw just to remember last time I tried I spent two
> > hours. I then used sfu, cd'ed in the source directory, ./configure,
> > make, strip and within 90 seconds my rsync build was ready to
> > download. SFU is free though not free as in free speech, but when
> > you've spent hours on msys/mingw, you can accept anything and be
> > really happy with it. *)
>
> Well, all it means is that Ocaml wasn't designed to build on Windows, that's
> it. MSYS provides what reasonably can be provided without a Unix emulation
> layer. THe fact that Oaml uses a Unix-centric build system and whatnot makes
> things the way they are. The windows build could dispense with configure and
> whatnot.

MSYS is far from providing anything sufficient. SFU is not an
emulation layer either : in my rsync example, I then ran my executable
outside of sfu. I think the executables are native to windows. As I've
said, msys has incredibly outdated headers : in one header, it defined
internet explorer version as 3... (hint, if you need a header for
msys, use those from wine). That's where the problem lies.
I've already worked on updated headers and compiler flags for cygwin.
You can get pthreads, dirent and tons of other things just by updating
a few text files. MSYS won't be a proper platform if this is not done
and wine has already done half the work.

About the windows build, it is already avoiding configure scripts but
then the options are determined by the lowest common factor because
since most of the required tools are not provided by windows (cc,
headers), you can't be sure about what is available. But then the
ocaml Makefile.nt files are already doing this.
Related is question 10 on this page :
http://www.interopsystems.com/SurveyResults.htm (yes, nearly 87%)


 ---
Adrien Nader