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