[Top][All Lists]

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

Re: managing ocaml dependencies

From: Guillaume Rousse
Subject: Re: managing ocaml dependencies
Date: Tue, 21 Nov 2006 14:21:58 +0100
User-agent: Thunderbird (X11/20061109)

Ralf Wildenhues wrote:
> 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:
> 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?
It fails if the file does not exist.

If the file exist, created by touch with an ad-hoc timestamp so as to be
automatically rebuild before the first target, it will not be reloaded,
meaning the build will fail.

Creation during configure time seems the only option, unless having an
additional 'make dep' setp between 'configure' and 'make' steps is used.
I think using automake will be cheaper here than reinventing it.

>> 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.
I initially thought it would be cheaper to solve autoconf and automake
issues separatly, but I'm changing my mind here. Let's solve this
dependency issue.

I've had a look at depcomp script. Basically, it seems I have to:
1) write my own ocamldep mode
2) force config.status to use it

For 1), the attached patch seems to be enough.

For 2), neither reading depout.m4 nor configure code is really helpful.
Moreover, some caml projects including C files, I may have to use two
different dependency tracking methods: one fixed by me for ocaml files,
one determined at configure time for C files.

reply via email to

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