On Thu, 2006-06-29 at 10:27 +1200, Jonathan Roewen wrote:
> > It isn't broken. The need to search the environment for the
> > interpreter is mandated by the requirement scripts invoking
> > the names of ocaml executables are transparent with respect
> > to both:
> >
> > (a) whether the code is bytecode or native code
> > (b) the machine it runs on
> >
> > Hard coding the location of the interpreter breaks
> > requirement (b): it prevents shipping bytecode
> > from one machine to another because two people may
> > have installed the interpreter in different places
> > (indeed may be running different OS!)
> 
> Err, what? OCaml already embeds the full path in bytecode (on
> unix-like systems). 

Then the codes won't be shippable.

> How should this be any different for an ocaml
> compiler tool?

It can be different for an installed tool set of ocaml
tools, but not for external executables such as CL.EXE,
gcc, etc. I not only can but DO upgrade these tools
independently of Ocaml.

Hard coding paths in executables is a bad idea.
The right way to do this is to make the client executables
(or libraries) arguments, and then provide a shell script 
which has these arguments hard coded. That way it's easy to 
reconfigure your system with a text editor.

IMHO of course. Hard coded paths are easier for dumb usage ..
until you get tied in a knot upgrading things and have no
idea what the problem is because the encoding isn't visible.
Coupling should be explicit -- basic design principle
(see OOSC, Meyer).

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net