English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Why does the order in the Makefile matter?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2000-11-02 (18:31)
From: Pierre Weis <Pierre.Weis@i...>
Subject: Re: Why does the order in the Makefile matter?
> On Sat, 28 Oct 2000, Pierre Weis wrote:
> > Hence, when the entire program is made of multiple implementation
> > files, those files must be linked in any order that is compatible with
> > the static binding rule: no definition can be linked if it refers to
> > an identifier that is defined after the definition at hand.  In
> > addition, expressions to be computed must evidently appear in any
> > order compatible with the desired runtime behaviour.
> I completely understand this point, and I agree that there are legal 
> Caml programs that have a different behavior depending on the order
> of the .cmo file linking. However, every program I write (and I suppose
> that's true for most of us) has an invariant behavior under all legal
> permutations of the .cmo files. Mostly because I only have 1 .ml file
> that actually does anything; the rest only contain side-effect-free
> definitions.

Hmm, no initializations ? For instance table allocations and
computations of default values are often considered side-effect free,
even if the initializations can perform some assignments.

Anyway what about identifiers redefinition ? Then the linking order
will influence the semantics (due to the binding of identifiers in
closures). Also, if there are more than one compatible linking order,
the compiler should prove that all those linking orders will lead to
the same semantics ?

> So it would be nice if the compiler itself could put the .cmo files
> in an order compatible with the static binding rule. This would
> remove the tedium of putting the .cmo files in an appropriate order
> from the programmer.

We can propose an external tool that will try to find for you some
order compatible with static binding if any, something similar to
ocamldep for module compilation dependancy. This existed in Caml Light
and was named ``lorder'':

  A tool to compute the dependencies between a set of .zo files
  and suggest a correct linking order.

> Would this be difficult to implement?

Have a look at the source code in the contrib directory of Caml Light:
you need some knowledge of the structure of .cmo files to extract the
name of the identifiers defined in here, then you just have to output
a depandancy graph and use the topological sort implemented in

> Perhaps this could be made a compiler switch?

I think it would be a bad idea, since you just have to use the tool
once and forall (or from time to time in case of linking failure). As
for ocamldep, you should have to run it outside the compiler (even if
this is done automatically by a Makefile entry).

> Stephan
> -- 
> ir. Stephan H.M.J. Houben
> tel. +31-40-2474358 / +31-40-2743497
> e-mail: stephanh@win.tue.nl

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/