dependency analysis

[Duncan Coutts]

On Mon, 2007-08-13 at 10:00 +0100, Neil Mitchell wrote:
> Hi Peter,
> 
> There is an existing implementation of some of the make stuff in Yhc,
> but separated into a stand-alone library:
> 
> http://darcs.haskell.org/yhc/src/libraries/make/
> 
> I am happy to work with you, and in particular to write the make
> library code. What would be useful is someone to integrate this make
> code with Cabal.

We realised yesterday that not only do we need to find the new deps of a
module when we've built it's main source dependency but we also then
need to make rules to build those deps, so dep analysis has to
interleave with making.

example:

rule to generate:
Foo.hs.cpp -> Foo.hs

now we have to find the deps of Foo.hs, eg Bar.hi and we may not already
have a Rule for Bar.hs -> Bar.hi since Bar may not have been an exposed
module.

So this isn't enough:


data Rule = Rule {
  produces :: [FilePath],
  requires :: [FilePath],
  dynRequires :: [FilePath],
  action   :: IO ()
}

while the dynRequires is ok for finding out that we need Bar.hi it's not
enough to get us the new Rule for generating Bar.hi

One option might be to add a dep chaser arg to the runMake function:

runMake :: [FilePath] -> [Rule] -> IO ()

that is add:

runMake :: [FilePath] -> [Rule] -> (FilePath -> IO [Rule]) -> IO ()

so that when it cannot find an existing rule to build a target, it calls
the dep chaser to see if it can come up with any more rules for it.

But perhaps the dynRequires and the dep chaser can be integrated
somehow, it feels a tad ad-hoc.

I do like the separation of the concrete build graph that refers to
actual files, and the layer that uses suffix rules and search paths to
do dep chasing. The question is just what the right interface between
the two should be given that we know that we have to do some build
actions to discover the complete build graph.

Duncan