automake
[Top][All Lists]
Advanced

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

Re: Automake and dependency generation for Haskell


From: Alexandre Duret-Lutz
Subject: Re: Automake and dependency generation for Haskell
Date: Sun, 30 Jan 2005 19:15:28 +0100
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

>>> "scrambles" == scrambles  <address@hidden> writes:

[...]

 scrambles> I would like it very much if I could get this kind
 scrambles> of order dependent compilation with automake,
 scrambles> perhaps using the depcomp wrapper, but of course I
 scrambles> don't know how to do it.

Sounds hard, because in automake Makefiles the dependency
tracking is done as a side-effect of compilation: i.e. no
dependency information is available before the first compilation.
That's OK when compiling C, but obviously not in your case.

(FWIW the manual has a section explaining the history of
dependency tracking in Automake.)

[...]

 scrambles> You might wonder how am I using automake at the
 scrambles> moment? Well I use a very nasty hack. GHC also
 scrambles> supports a --make flag. For example if you issue the
 scrambles> command:

 scrambles> ghc --make Foo.hs
 scrambles> (Haskell filenames end in ".hs".)

 scrambles> GHC will compile Foo.hs to Foo.o, but it will first
 scrambles> compile anything that Foo.hs depends on. Normally it
 scrambles> tries to link the whole thing into an executable,
 scrambles> but you can stop it from doing this with another
 scrambles> flag.

 scrambles> My hack is to compile all the files in whatever
 scrambles> order they appear in Makefile.am, giving GHC the
 scrambles> --make flag so that it can cope with the dependency
 scrambles> issues.  The downside of this is that it causes GHC
 scrambles> to re-read many files during the whole compilation,
 scrambles> most of the time it realises that it has already
 scrambles> compiled the file previously and avoids
 scrambles> re-compilation, however there is still a
 scrambles> considerable slow down.

Why does it "re-read many files"?  Shouldn't it just compare
time stamps like make would do?  (And if so, why would it be
slower than make?)

Anyway, an idea would be to write a depcomp than use --make and
-M during the first compilation, and use only -M for later
recompilation.  That's would be an improvement for all but the
first compilation.
-- 
Alexandre Duret-Lutz





reply via email to

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