From: "Nicolas Pouillard" <nicolas.pouillard@inria.fr>
To: skaller <skaller@users.sourceforge.net>
Cc: "Guillaume Rousse" <Guillaume.Rousse@inria.fr>,
caml-list@yquem.inria.fr, autoconf@gnu.org
Subject: Re: [Caml-list] managing ocaml dependencies
Date: Thu, 16 Nov 2006 22:43:47 +0100 [thread overview]
Message-ID: <cd67f63a0611161343m612d410re129617ded99ec6a@mail.gmail.com> (raw)
In-Reply-To: <1163695632.20151.34.camel@rosella.wigram>
On 11/16/06, skaller <skaller@users.sourceforge.net> wrote:
> On Thu, 2006-11-16 at 15:20 +0100, Guillaume Rousse wrote:
> > I'm trying to use autoconf for ocaml project, and I have troubles with
>
> > They are two different strategies here, either generate them on
> > maintainer host and ship them in the distribution, either generate them
> > on user's host.
>
> There is no choice: it has to be done by the developer
> because sometimes the dependency is semantic, in particular
> when order of initialisation matters.
When order of initialization matters, just enforce it.
>
> For example:
>
> (* file 1 *)
> let a : int opt = ref None
> ;;
>
> (* file 2 *)
> let _ = a := Some 99
> ;;
>
> (* file 3 *)
Just add something like:
open File2;; (* because initialization order matters *)
Or if really don't want use open:
module File2 = File2;; (* because initialization order matters *)
Or if really don't want re-export that module (if you don't have a .mli):
let module File2 = File2 in ();; (* because initialization order matters *)
> let _ =
> match !a with
> | None -> failwith "WRONG INIT ORDER"
> | Some x -> print_endline (string_of_int x)
> ;;
>
> You must link in the given order. Ocamldep can tell
> 2 and 3 depend on 1, but not that 3 depends on 2.
>
> > The second strategy, however, heavily relies on make implementation.
> > Whereas GNU make happily generate .depend file on the fly with previous
> > snippet, some other implementations don't, such as Digital Unix's one
> > (and potentially others).
> > Make: Cannot open ../.depend. Stop.
>
> This is easy to fix: generate a new_makefile and then use
> a rule something like:
>
> cat new_makefile_prefix .depend > new_makefile
> make -f new_makefile
>
> Since this is a rule, the order of evaluation is strict.
>
--
Nicolas Pouillard
next prev parent reply other threads:[~2006-11-16 21:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-16 14:20 Guillaume Rousse
2006-11-16 16:47 ` [Caml-list] " skaller
2006-11-16 19:01 ` Jean-Christophe Filliatre
2006-11-16 21:43 ` Nicolas Pouillard [this message]
2006-11-17 0:36 ` skaller
2006-11-16 21:21 ` Ralf Wildenhues
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=cd67f63a0611161343m612d410re129617ded99ec6a@mail.gmail.com \
--to=nicolas.pouillard@inria.fr \
--cc=Guillaume.Rousse@inria.fr \
--cc=autoconf@gnu.org \
--cc=caml-list@yquem.inria.fr \
--cc=skaller@users.sourceforge.net \
/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