Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
To: Guillaume Rousse <Guillaume.Rousse@inria.fr>
Cc: autoconf@gnu.org, caml-list@yquem.inria.fr
Subject: Re: managing ocaml dependencies
Date: Thu, 16 Nov 2006 22:21:15 +0100	[thread overview]
Message-ID: <20061116212114.GA6290@iam.uni-bonn.de> (raw)
In-Reply-To: <455C73BA.1030803@inria.fr>

Hello Guillaume,

Do you use Automake?  If yes, or if you want to add support for ocaml to
Automake, then probably its list would be more appropriate.  If not, all
of the following has relevance without Automake, it's just colored that
way a bit.

* Guillaume Rousse wrote on Thu, Nov 16, 2006 at 03:20:42PM CET:
> I'm trying to use autoconf for ocaml project, and I have troubles with
> managing dependencies.
> 
> They are generated through a specific program, ocamldep, that basically
> output makefile rules, so as to be used this way:
> .depend:
> 	$(OCAMLDEP) *.ml *.mli > .depend
> 
> include .depend
> 
> 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.

FWIW, Automake's strategy is building them on the user's system.  There
is a chapter in its manual that contains rationale:
http://sources.redhat.com/automake/automake.html#Dependency-Tracking-Evolution

Further, the macro AM_MAKE_INCLUDE in automake/m4/make.m4 detects the
'include' style used by 'make'.  The automake way to handle
bootstrapping is to create (almost empty) per-target files at
config.status execution time (see m4/depout.m4), and update them as a
side effect of compilation (see m4/depend.m4 and lib/depcomp).  The side
effect method is more efficient once you have a compiler that can output
dependency information on the fly (such as GCC for some languages).

> 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.

Does that mean it fails if it updates a file that is included, or that
it merely fails the first time when the file does not yet exist?

> I also discovered than GNU make use current directory to resolve path of
> included files, even when the inclusion directive is found in an
> included makefile, whereas Digital Unix's one consider the directory
> containing the makefile containing the inclusion directive instead.
> 
> Given the following setup:
> |-- Makefile.rules
> `-- a
>     `-- Makefile
> 
> If the inclusion directive is given in top level Makefile.rules, itself
> included in lower level a/Makefile, GNU make resolve the .depend file in
> a directory, whereas Digital Unix resolve it in top-level directory.

Ah, thanks, I did not know that.  (Automake does not use recursive
inclusion at 'make' run time; not to be mistaken with the automake
'include' which is resolved at 'automake' run time.)

> Finally, it seems the safest strategy would be to use configure to
> produce those .depend file, or is there any other possibility ?

Yes, that's the idea.  I think adapting Automake for ocaml should be
possible.  If you go and add support for it in Autoconf first, then it
can be made quite seamless, too.  For examples how to do this, you could
peek at how Erlang support was recently added to Autoconf, and UPC to
Automake.

Cheers,
Ralf


      parent reply	other threads:[~2006-11-16 21:21 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
2006-11-17  0:36     ` skaller
2006-11-16 21:21 ` Ralf Wildenhues [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=20061116212114.GA6290@iam.uni-bonn.de \
    --to=ralf.wildenhues@gmx.de \
    --cc=Guillaume.Rousse@inria.fr \
    --cc=autoconf@gnu.org \
    --cc=caml-list@yquem.inria.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