Request: Windows installers

Request: Windows installers

[skaller]

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

I have a small request for the Ocaml Windows installers:

There are TWO Windows based Ocaml ports: MinGW and Win32 native
plus the Cygwin port.

Please could the builders of these packages 
distinguish them??

Make the default install points, desktop icons, menu items,
etc all distinct. Plus, with the OcamlWinPlus thing, make sure
the port/version of Ocaml being used is displayed on the titlebar: 
even the help/about does not tell you this (hmm .. and 'ocaml'
command should tell you this too)

I have, and need, all three versions of Ocaml installed,
and it is all very confusing, both MingW and native ports
think they own the world and use the same OCAMLLIB variable,
and also both expect themselves to be first in the PATH.

Please don't add the binary directory to the system PATH
without asking, just as for registering Ocaml file types,
please DO ask whether to do this (for installing both
ports .. the answer will be NO in both cases).

For the MinGW port it is required to use Cygwin? the port
doesn't appear to actually work with MSYS (standalone
Mingw tools including gcc/as and bash)? 

The Windows native version using native code compiler
seems to work provided you have the assembler ML.EXE 
and ML.ERR installed, but you also seem to need 
MSVC++ compiler CL.EXE and some .lib and .dll files.

I don't quite understand why CL.EXE is required,
why isn't LINK.EXE good enough? Isn't everything
done via assembler?

Anyhow, helloworld.ml compiles to native code fine using
ML.EXE 6.15, and Visual Studio Pro 2003 versions of 
CL.EXE plus the required Lib and Dll files. 

[If someone knows how to fix the PATH variable pls
email me privately .. I forget how to edit 
environment variables .. :]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Request: Windows installers

[Christopher A. Watford]

On 8/31/05, skaller <skaller@users.sourceforge.net> wrote:
> I have a small request for the Ocaml Windows installers:
> 
> There are TWO Windows based Ocaml ports: MinGW and Win32 native
> plus the Cygwin port.
> 
> Please could the builders of these packages
> distinguish them??
> 
> Make the default install points, desktop icons, menu items,
> etc all distinct. Plus, with the OcamlWinPlus thing, make sure
> the port/version of Ocaml being used is displayed on the titlebar:
> even the help/about does not tell you this (hmm .. and 'ocaml'
> command should tell you this too)

I'll fix that. In my copy Help -> About does, but the entire thing is
built such that it doesn't need to know the version. Unfortunately the
best thing I can do is grab the first line from ocaml.exe... which is
fugly. If the EXE is stamped I'll take out of the NT image headers.

OCamlWinPlus really needs an embedded toplevel. Because piping in that
toplevel is a sonofabitch. I could spruce the thing up big time or
drop it into Eclipse/MSVS if I could step through the toplevel code
wise. Alas I'm not quite sure how to start this.
 
> I have, and need, all three versions of Ocaml installed,
> and it is all very confusing, both MingW and native ports
> think they own the world and use the same OCAMLLIB variable,
> and also both expect themselves to be first in the PATH.

Personally MingW should come second to MSVS. But I don't think your
'first in PATH' to be correct.

> Please don't add the binary directory to the system PATH
> without asking, just as for registering Ocaml file types,
> please DO ask whether to do this (for installing both
> ports .. the answer will be NO in both cases).

I agree.

> For the MinGW port it is required to use Cygwin? the port
> doesn't appear to actually work with MSYS (standalone
> Mingw tools including gcc/as and bash)?
> 
> The Windows native version using native code compiler
> seems to work provided you have the assembler ML.EXE
> and ML.ERR installed, but you also seem to need
> MSVC++ compiler CL.EXE and some .lib and .dll files.
> 
> I don't quite understand why CL.EXE is required,
> why isn't LINK.EXE good enough? Isn't everything
> done via assembler?

CL is the primary on that 'toolchain'. I was unaware of being able to
go around it.

> Anyhow, helloworld.ml compiles to native code fine using
> ML.EXE 6.15, and Visual Studio Pro 2003 versions of
> CL.EXE plus the required Lib and Dll files.
> 
> [If someone knows how to fix the PATH variable pls
> email me privately .. I forget how to edit
> environment variables .. :]
> 
> --
> John Skaller <skaller at users dot sourceforge dot net>
> 

My thoughts, I'll get on the OCamlWinPlus stuff right now.

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

Re: [Caml-list] Request: Windows installers

[skaller]

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

On Wed, 2005-08-31 at 20:26 -0400, Christopher A. Watford wrote:
> On 8/31/05, skaller <skaller@users.sourceforge.net> wrote:
> > I have a small request for the Ocaml Windows installers:
> > 
> > There are TWO Windows based Ocaml ports: MinGW and Win32 native
> > plus the Cygwin port.
> > 
> > Please could the builders of these packages
> > distinguish them??


> I'll fix that. 

Great! Thanks. Only a small thing: not many people will have
multiple Camel's installed, but some Felix developers will,
at least whilst we're trying to get all the different build
configurations to work ;(

> > I have, and need, all three versions of Ocaml installed,
> > and it is all very confusing, both MingW and native ports
> > think they own the world and use the same OCAMLLIB variable,
> > and also both expect themselves to be first in the PATH.
> 
> Personally MingW should come second to MSVS. But I don't think your
> 'first in PATH' to be correct.

I'm not even sure why OCAMLLIB is set: the doco claims it isn't
needed for XP. Probably you're right about the PATH thing,
I'm not sure: how does bytecode find ocamlrun?

> > I don't quite understand why CL.EXE is required,
> > why isn't LINK.EXE good enough? Isn't everything
> > done via assembler?
> 
> CL is the primary on that 'toolchain'. I was unaware of being able to
> go around it.

Well, there is a linker, LINK.EXE .. and an assembler, ML.EXE,
so why would you need a C/C++ compiler if ocamlopt generates
assmebler only?

Anyhow thanks: it's only a minor thing .. but it is very
confusing, especially OCAMLLIB, since it even influences
the Cygwin version of Ocaml (and then can't find Pervasives)

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Request: Windows installers

[Christopher A. Watford]

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

Re: [Caml-list] Request: Windows installers

[skaller]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

On Fri, 2005-09-02 at 12:17 -0400, Christopher A. Watford wrote:

> > 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 ....

Ah, but that won't work if you need to call the system() function,
which requires a single line .. perhaps

SET OCAMLLIB=xxx && ocamlc ...

will work with CMD.EXE?

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

I didn't mention .. the scripts are Python.. :)

I can use os.putenv() .. but that affects the current
process too. I can also pass the environment if I use

execle()

but that is a superior pain .. maybe i will have to write
an env.exe command for windows .. ;(

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]