caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Christopher A. Watford" <christopher.watford@gmail.com>
To: caml-list@yquem.inria.fr
Cc: skaller <skaller@users.sourceforge.net>
Subject: Re: [Caml-list] Request: Windows installers
Date: Fri, 2 Sep 2005 12:17:06 -0400	[thread overview]
Message-ID: <8008871f0509020917509eadda@mail.gmail.com> (raw)
In-Reply-To: <1125640801.7223.18.camel@localhost.localdomain>

On 9/2/05, skaller <skaller@users.sourceforge.net> wrote:
> On Thu, 2005-09-01 at 14:23 -0400, Christopher A. Watford wrote:
>
> What I meant was that if you have TWO or even THREE Ocaml's installed,
> then some ocaml tools may call others and rely on the PATH to
> find them. If this the case, those tools will NOT work correctly.
> EG with a path like:
> 
>        PATH=/Cygwin/usr/bin; /MingwOcaml/bin; /NativeOcaml/bin
> 
> and you run
> 
>        /MingwOcam/bin/ocamlopt
> 
> what will happen? Will it use the right gcc? Will ocamlopt,
> which is a bytecode program, use the Cygwin ocamlrun instead
> of the mingw ocamlrun?
> 
> The only way this can work is if the program using another
> program knows the installation root. It isn't clear how
> that could possibly work on brain dead systems like
> Unix and Windows: perhaps on the old Mac where code had
> resource forks it might work.

Well my solution to this is the registry is maintained better. Like:

HKLM -> INRIA -> Objective Caml -> X.YY.Z:
-- OCAMLLIB  (regstring): "M:\path\to\lib"
-- OCAMLBIN (regstring): "M:\path\to\bin"

Which then you as the coder would be responsible for looking these
values up. If the damn executables were stamped with a version number
you could search the path for all ocaml.exe's and check for the
version you want from the image headers. I may have OCamlWinPlus
search every dir on the path at startup (with a checkbox to disable
that for future starts) to find all interpreters available. It would
then deduce the OCAMLLIB path from the exe's path, but give the user
the option of changing it. You could then do:

File -> Change Toplevel ...

This is probably the best you can get in this situation.

> Encoding absolute pathnames is bad. Using relative lookup
> is also bad. The thing is, Unix is just plain bad: the
> file system is wrong, as is the language it is based on, C.
> 
> The file system should represent commands (executable files)
> the same was as C should have done it, which is the way
> Ocaml does do it: with closures.
> 
> > Not sure on the OCAMLLIB bit. Relevant code is startocaml.c:261:
> >
> > // Set the OCAMLLIB environment variable
> > SetEnvironmentVariable("OCAMLLIB", LibDir);
> >
> > It does this right before starting ocamlrun. I would imagine this is
> > necessary for ocamlrun, but hey, things might have changed.
> 
> Yes, but I'm not using ocamlrun, I'm using ocamlopt.opt, and
> it doesn't seem to do this: if OCAMLLIB is set to the wrong
> value, linkage fails.
> 
> I haven't been able to get it to work with OCAMLLIB="" either,
> despite claims in the documentation that this is only needed
> under Win98 etc, it seems to be needed on XP as well, and
> it has to be correct. This is slightly nasty for my build
> scripts .. I have to calculate the correct OCAMLLIB to use
> for a given 'ocamlc/ocamlopt' and run it like
> 
> env OCAMLLIB=xxxx ocamlc ....
> 
> ... I'm not sure how to do that with Win32 shell CMD.EXE.

C:\> SET OCAMLLIB=xxx
C:\> ocamlc ....

> My scripts all use system() function calls, which is
> rather nasty .. turns out even under Cygwin, system()
> calls CMD.EXE after one level of indirection (or something
> similar .. I haven't quite worked it out).

You can use SetEnvironmentVariable() with windows before your system()
calls if you would like.

#include <windows.h>
#pragma comment(lib, "kernel32.lib")
BOOL SetEnvironmentVariable(
  LPCTSTR lpName,
  LPCTSTR lpValue
);

> 
> --
> John Skaller <skaller at users dot sourceforge dot net>

Hope that helps

-- 
Christopher A. Watford
christopher.watford@gmail.com
http://dorm.tunkeymicket.com


  parent reply	other threads:[~2005-09-02 16:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-31 22:03 skaller
2005-09-01  0:26 ` [Caml-list] " Christopher A. Watford
2005-09-01 12:57   ` skaller
     [not found]     ` <8008871f0509011123621c1d7a@mail.gmail.com>
     [not found]       ` <1125640801.7223.18.camel@localhost.localdomain>
2005-09-02 16:17         ` Christopher A. Watford [this message]
2005-09-02 17:34           ` skaller

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=8008871f0509020917509eadda@mail.gmail.com \
    --to=christopher.watford@gmail.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=skaller@users.sourceforge.net \
    /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).