Version française
Home     About     Download     Resources     Contact us    
Browse thread
Request: Windows installers
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Christopher A. Watford <christopher.watford@g...>
Subject: Re: [Caml-list] Request: Windows installers
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