autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: managing ocaml dependencies


From: Ralf Wildenhues
Subject: Re: managing ocaml dependencies
Date: Thu, 16 Nov 2006 22:21:15 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]