From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: Tom.Hirschowitz@ens-lyon.fr
Cc: caml-list@inria.fr, romain.bardou@dptinfo.ens-cachan.fr
Subject: Re: [Caml-list] modifying ocaml sources
Date: Mon, 20 Jun 2005 10:15:41 +0900 (JST) [thread overview]
Message-ID: <20050620.101541.59497922.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <17074.46980.394501.898095@gargle.gargle.HOWL>
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
prev parent reply other threads:[~2005-06-20 1:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-17 11:44 Tom Hirschowitz
2005-06-20 1:15 ` Jacques Garrigue [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050620.101541.59497922.garrigue@math.nagoya-u.ac.jp \
--to=garrigue@math.nagoya-u.ac.jp \
--cc=Tom.Hirschowitz@ens-lyon.fr \
--cc=caml-list@inria.fr \
--cc=romain.bardou@dptinfo.ens-cachan.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox