Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Building large and portable projects
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Nicolas Cannasse <warplayer@f...>
Subject: Re: [Caml-list] Building large and portable projects
> > What is the difference with OCamake ?
> > http://tech.motion-twin.com/ocamake/
>
> There are a lot of things that OCamake can't do.  What would be very
> nice would be a tool that makes it easy to build simple Ocaml programs,
> but also lets me, reasonably easily, manage directory trees, C bindings,
> C libraries, programs build with special, strange programs, etc...
>
> There are several packages in the scons approach that seem like good
> ideas, but they all make very heavy use of the scripting languages they
> are written in.
>
> I still haven't found anything nicer than gnatmake, the builder for Gnu
> Ada.  A common compilation line:
>
>   gnatmake mainmodule
>
> Builds mainmodule.adb, as well as everything it depends on.  You can set
> a path to search for parts.  This would work for ocaml, if a program had
> a single module that brought in everything necessary via dependencies.

I agree such a thing would be very useful.

The first problem I see is that right now ocamldep is only giving you the
dependencies between files that are listed in the ocamldep command. That
means that you already need to know all the files before generating the
dependencies between them.

The other problem is that to much of the "special programs build" are
relying on OS tools that are sometimes not stricly compatible. The solution
to this is to rewrite all the tools in pure ocaml ( or with a small portable
C binding ) to give the "makefile" writter an API of portable commands. It
looks like this is the goal of Sylvain, and that would be really something
nice.

About OCamake : yes right know it only supports compilation of
ml/mli/mll/mly files in a standard way, but it is now mature and is actually
handling a lot of cases such as projects with multiple files paths and a
best effort dependency resolver (although based on ocamldep output). Adding
the auto building of C stubs could be done but this kind of tool need a lot
of time in order to fix correctly all the small issues.

Nicolas Cannasse


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