caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Dave Berry <dave@kal.com>
To: Chris Hecker <checker@d6.com>, Xavier Leroy <Xavier.Leroy@inria.fr>
Cc: caml-list@inria.fr
Subject: [Caml-list] RE: OCaml for Windows: a suggestion
Date: Wed, 14 Feb 2001 17:50:30 -0000	[thread overview]
Message-ID: <3145774E67D8D111BE6E00C0DF418B663F5B7F@nt.kal.com> (raw)

> -----Original Message-----
> From: Chris Hecker [mailto:checker@d6.com]

> A couple of suggestions were made for the Windows OCaml port. 
>  I disagree with both. 

> 1. making the port a gcc port rather than an msvc port

I agree that most production programmers use MSVC.  The question is whether
they/we need to compile the compiler, and whether they/we will be willing to
install GCC and Cygwin to build the system (as opposed to using it).  My
personal opinion is that I'd prefer MSVC, to avoid cluttering my machine
with other applications, but if this restricts the functionality of the
system, then I'd be willing to install Cygwin.  If I didn't already own a
copy of MSVC on my home machine, I might have a different opinion.

> 2. moving most of the runtime code into DLLs
> 
> This would be fine as an option, but there has to be a way to 
> make a standalone exe that only depends on default installed 
> Win32 dlls (user32.dll, kernel32.dll, advapi32.dll, 
> ws2_32.dll, etc.).  If I have to send a bunch of dlls along 
> with my exe for anybody to use my program then I'm _MUCH_ 
> less likely to use ocaml for anything real.  

My experience is that most production code builds an InstallShield or
similar installer, so users don't see all the files that are installed.
Even if you just use a zip file, all you need to do is to put the DLLs in
the same folder as the executable.

If the aim is to install a system-wide OCaml runtime DLL (and Cygwin, if
needed), then that is more complicated.  You can run into versioning
problems, if two applications are built to use different versions of the
runtime.  You also need a scheme for supplying the DLLs, and only installing
them if they aren't already installed.  Probably the simplest way to do this
is to provide boiler-plate installer code that people can adapt to build
their own installers.

> My suggestions are the following, 
> ...
> 3.  Generics. 

I believe OCaml supports functors, i.e. parameterised modules.  Did you have
something else in mind?

Dave. 
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr


             reply	other threads:[~2001-02-14 17:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-14 17:50 Dave Berry [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-02-13  4:36 Hao-yang Wang
2001-02-13 16:25 ` [Caml-list] " Brian Rogoff
2001-02-12 21:27 Lionel Fourquaux
2001-02-14 15:32 ` [Caml-list] " Vijay Chakravarthy
2001-02-13 18:07   ` Mattias Waldau
2001-02-13 18:20   ` Gerd Stolpmann

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=3145774E67D8D111BE6E00C0DF418B663F5B7F@nt.kal.com \
    --to=dave@kal.com \
    --cc=Xavier.Leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=checker@d6.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).