[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2005-06-20 (01:23) |
From: | Jacques Garrigue <garrigue@m...> |
Subject: | Re: [Caml-list] modifying ocaml sources |
From: Tom Hirschowitz <tom.hirschowitz@ens-lyon.fr> > We are trying to modify the ocaml compiler in order to have it verify > the well foundedness of recursive module definitions, and have a > question for the long standing ocaml source hackers. Interesting endeavour. Of course I hope that you can handle my pet case: http://www.math.nagoya-u.ac.jp/~garrigue/papers/mixmod5.ml.txt > >From early experiments, it seems that the dependencies in the various > .depend files are insufficient. For example, try to modify the version > string, say "3.08.3", in stdlib/sys.cmo, and make the world. Launch > the new toplevel; nothing has changed. How do people deal with this > issue? In the cases we have, cleaning up the executables before making > the world again is enough. Is it in general? There are indeed a few things that are not redone automatically. But of course make clean; make world should always solve the problem; except when you have changed some internal data and you need to bootstrap. The kinds of problem I see frequently are: * after modifying the standard library implementation, need to relink everything. Dirty workaround: touch utils/config.ml; this will force to relink the compilers, but not all tools. * any change in the interface of a standard library module used somewhere in the compiler requires recompilation. Generally you're better off recompiling everything than trying to track the dependencies by hand. * after changes in the compiler, ocamlbrowser compilation breaks sometimes. (cd otherlibs/labltk/browser; make clean) solves it. The dependencies are not all that clever because: * some cases are really cyclic (eg ./ocamlc and the standard library clearly depend on each other) * having too many dependencies automatically enforced can be a pain. (For instance, on slow machines I sometimes disable the rule forcing ocamlc.opt and ocamlopt.opt to be recompiled from scratch everytime ocamlopt has changed.) Jacques Garrigue