Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Announcing the OMake build system version 0.9.1
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: chris.danx <chris.danx@n...>
Subject: Re: [Caml-list] Announcing the OMake build system version 0.9.1
David Brown wrote:
> Amen.
> 
> I asked a few years back why nobody had developed a tool similar to
> 'ghc --make' for Haskell or 'gnatmake' for Ada.  The idea is that you give
> it the main module, and the tool works out all of the rules in advance.
> 
> There are a couple of problems with these systems, especially in regards to
> ocaml.  But, I think there are things to learn from them.
> 
>   - They tend to be very tied to their specific language.  When source
>     files in this language are themselves generated, this either has to be
>     encoded in the make tool (yuck), or the make tool wrapped in a
>     makefile, which kind of defeats the purpose.

I don't understand what you mean by this, but surely having a tool for 
the most common purposes is better than no tool at all.  I also don't 
see how resorting to make defeats the purpose.  I have had to do this 
with gnatmake when making and using libraries.  Gnatmake builds the 
library but the library needs to exist before you can build the rest of 
the program so you need someway to tell it to biuld the lib first. 
Gnatmake doesn't handle that case.


>   - Ocaml allows arbitrary code to be executed during module elaboration
>     (to borrow an Ada term).  This causes two issues: 1.  elaboration order
>     can be significant, and 2.  modules can be required for the system, but
>     not be dependent (in a module sense) on the "main" module.  This also
>     means that the notion of a main module is less meaningful on ocaml.

Ada has the elaboration problem and it is up to the programmer to solve. 
:)  The programmer needs to know the elaboration order they want in 
order to get the program to work.  If there are elaboration issues the 
programmer must solve them themselves unless the tool can sort them out 
for them.  I see no problem with this.

Perhaps I'm missing something, but I don't see the 2nd problem either. 
The main module depends on modules which depend on modules.  When module 
X depended on by module Y depended on by main changes, X is recompiled, 
then Y then main.  All other modules not dependant on X, Y and main are 
unchanged.  "main" depends on modules, but to me those modules do not 
depend on main.


Chris

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