caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Xavier Leroy <xavier.leroy@inria.fr>
To: fred@ontosys.com
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Yet Another Compilation Question: lablgtk for windows + cygwin-mingw
Date: Tue, 6 Aug 2002 10:59:08 +0200	[thread overview]
Message-ID: <20020806105908.A11091@pauillac.inria.fr> (raw)
In-Reply-To: <20020805120530.A11782@ontosys.com>; from fred@ontosys.com on Mon, Aug 05, 2002 at 12:05:31PM -0500

> I've been planning to build an interactive application with OCaml that
> will be deployed primarily on Windows, so I'd like to understand your
> warning better.

I know I haven't made myself very clear, but basically what I'm
suggesting is: if you develop a Windows application using many tools
and libraries that come from a Unix background (e.g. gcc, ocaml, GTK),
it might be more effective to develop the application first under
Unix, then port it to Windows.  This way, during development, you
don't get bitten by potential quirks in the Windows ports of the tools
and libraries.

> 1. Is the risk just in developing (compiling, packaging) on Windows,
>    or also in deploying to Windows?

I think deployment under Windows is OK -- binary distributions work
well under Windows, better than under Unix :-)  I was really thinking
about development and setting up the development environment -- just
installing the necessary development software under Windows can be
significantly harder than under Unix.

> 2. What do you mean by "piling port after port"?  Do you mean
>    reworking the application to track changes as the various tools
>    (GNU+OCaml+labltk+GTK) evolve in successive releases?

I was mostly thinking about working around bugs and quirks in the
Windows ports of the tools and libraries.  For instance, while OCaml
tries hard to be OS-neutral, some libraries (e.g. Unix) have an API
that is slanted towards Unix, and are only 95% implemented under
Windows.  (For instance: Unix.select can take a mixture of pipe and
socket descriptors under Unix, but only sockets under Windows.)

Another issue is getting support from developers.  This is especially
true if the original software and the Windows port are maintained by
separate teams.  The core (Unix) developers tend to brush your
questions aside as "Windows lossage", while the porting team may not
fully understand the original software...

These are minor inconveniences, but they pile up if you use several
"ported to Windows" components.  

>    Has this
>    been a big problem in applications such as Unison?  (Or any
>    other broadly deployed OCaml app?  I don't know of others.)

The examples that I have in mind were all developed first under Unix,
then ported to Windows.

> 3. Is there some other GUI framework that you expect will entail less
>    suffering than lablgtk+GTK?

I can't really comment here, since I don't do GUIs :-)

> 4. As the porting problem applies to the GNU compilers and OCaml
>    itself, are you warning us against developing OCaml applications
>    for use on Windows?

No.  Please go ahead and we'll support your efforts.  But I'm warning
you that you should expect a few additional difficulties compared with
developing under Unix first.

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  reply	other threads:[~2002-08-06  8:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-05 13:49 Kontra, Gergely
2002-08-05 14:40 ` Xavier Leroy
2002-08-05 17:05   ` fred
2002-08-06  8:59     ` Xavier Leroy [this message]
2002-08-06  9:52     ` Nicolas Cannasse
2002-08-08 14:07   ` Alan Schmitt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020806105908.A11091@pauillac.inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=fred@ontosys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).