2 Nov 2000 19:22
Re: Why does the order in the Makefile matter?
Pierre Weis <Pierre.Weis <at> inria.fr>
2000-11-02 18:22:40 GMT
2000-11-02 18:22:40 GMT
> 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'': 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 contrib/tsort.ml > 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 <at> win.tue.nl Pierre Weis INRIA, Projet Cristal, Pierre.Weis <at> inria.fr, http://cristal.inria.fr/~weis/