>>> "scrambles" == scrambles <[EMAIL PROTECTED]> 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
