Re: [Caml-list] Building large and portable projects

[skaller <skaller@ozemail.com.au>]

On Sun, 2003-11-23 at 04:08, David Brown wrote:
> On Sat, Nov 22, 2003 at 03:12:48AM +1100, skaller wrote:
> 
> > For example .c -cc--> .o -link--> exe, we can 
> > use the cached .o instead of running cc on the
> > .c provided the .c is older.
> 
> Older is incorrect, as well.  The program should run cc on the .c
> provided that the .c is different than the one used to produce the .o.
> Timestamps are useful as a cache, but a proper tool will need to use
> file hashes, or something to properly detect a file changing.

Yeah, that's a good point.

> An unrelated annoyance I've found is that ocamlc doesn't allow for the
> objects to be stored in a separate directory from this source.  This
> makes things, such as multiple configurations, multiple targets
> difficult.  Since ocamlopt doesn't currently support cross compilation,
> anyway, this is less of an issue.

It is still an issue if you have multiple Ocaml installations:
I actually ought to have 3 of them:

(a) the standard one my Linux came with
(b) the lastest release
(c) the CVS version

I need (a) to run system scripts (/usr)
I need (b) to check my code runs for clients (/usr/local),
and I need (c) cause I love playing with Ocaml :-)))

In addition I have to build my software at least in both
binary and bytecode form to check clients on
non-Linux platforms have some chance of using my product
if they can't get a native code compiler.

And then, there are versions of third party libraries ... ouch.

I have a starting concept here: I call it 'mount points'.
And another called 'mount stacks'.

A mount point is a root, specified as an OS native
directrory name. Files and directories down from
the mount point are always specified using Unix
convention (no matter what platform).

Then we have stacks. We start at the top mount
point of the stack and look for a file, going
down until we find it. However we always write
on the bottom. Here is a stack:

	/usr/lib/ocaml
	/usr/local/lib/ocaml
	/home/skaller/ocaml

The idea is you had hide *some* files
with an updated file, but don't need to
hide them all with a completely new distribution.
[A variant would just use patch files]

Additionally, writes (of object files etc) are
always most local and so don't interfere with
administrator installed compiled versions.

Another key part of it is relative file lookups.
The relativity is to a directory stack NOT
a particular directory so eg C #include "foo.h"
inside the file "bar.h" will follow the same
stack search algorithm except it will look
in the mount point of the stack + the subdirectory
of the file "bar.h".

A path is a sequence of stacks of mount points.

[It is also worth studying Kpathsea here ..]


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners