[Top][All Lists]
[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