On Tue, 2009-01-20 at 18:40 -0500, Peter Gavin wrote: > On 1/20/2009 5:47 PM, Peter Gavin wrote: > > I added a rule to the makefile > > > > dep: $(EARLY_DEPS) > > > > where EARLY_DEPS contains tools/c2hs/c2hsLocal.deps and additionally > > any dep files generated with chsDepend. I also made it so make won't > > try to include the libHS*_a.deps files when building the dep target. > > Now, make dep will build these dependency files without any errors > > happening. After make dep is done, make can be run from start to > > finish without errors. I also added a line to the configure script > > making it run make dep at the end of config.status, so no build > > processes will need to be changed. I figure everything should still > > work ok for partially complete builds and rebuilds for developers etc. > > > I found a way to do this so that make dep will be run from make instead > of configure. Since automake's "all" target recursively runs make > all-am, I made the all target depend on the dep target. So then make > all will generate all the dependencies before recursing with make > all-am. What do you think?
Well, that pretty much amounts to what we had before: have make build dependencies (including c2hs and all .hs files) before building the rest. Except with the previous solution you invoke make recursively and use make's magic to include dependencies in original invocation whereas your solution first builds dependencies and then invokes make recursively to build everything. I think the previous solution is better, actually, since you can say 'make blah.hs' and it will rebuild the dependencies (if they are not there) whereas your solution will not rebuild the dependencies. The problems that crop up at the user site (when they need to run 'make distclean') relates to the choice not to rebuild dependencies once they've been built. Whenever the import relations between modules change the dependencies can be wrong and the build can fail. This happens a lot when people run 'darcs pull'. The choice not to rebuild the dependencies was a performance consideration. Since calculating dependencies is rather quick on modern computers, it should be acceptable to always rebuild dependencies and get rid of all dependency problems. For automatic dependency calculation, we probably need to say that a specific .deps file depends on all source files of that library. However, I don't know if that works out of the box. In a nutshell: I'd rather go back to the original way dependencies are built since your solution seems slightly worse. Cheers, Axel. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
