Re: [Gtk2hs-devel] Gtk2HS 0.10.0 release candidate available

[Peter G. <pg...@gm...>]

On 1/21/2009 2:39 AM, Axel Simon wrote:
> 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.
>    
The difference is that before, the recursive make was attempted every 
time c2hs got run, while now, make knows what the real dependencies are 
and can proceed appropriately.  The first step of building the 
dependencies is just to bootstrap.  During the actual build, make still 
knows that the dep files are generated from the source files, and will 
update them as necessary (like they were before).

If for instance, you modify a gtk source file (e.g. to add an import 
statement), and just run make libHSgtk.a to rebuild just that library, 
the dependencies should still be regenerated for the file that was modified.
> 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.
>    
The dependency files are still rebuilt whenever any source file changes, 
since there is a dependency from every .dep file to the sources that are 
read in producing it.  Technically, you really don't want the object 
files or source files to depend on the .dep files; their not really 
dependencies, any more than the makefile itself is.  If you want to 
rebuild a single file using e.g., make foo/bar.o, that will work, unless 
the tree is completely clean (in which case I think it will still work, 
you'll just get the error that we talked about earlier).  In any case, 
make dep should always bring the tree up to where make foo/bar.o *will* 
work.  And really, all that is absolutely needed to bootstrap the rest 
of the dependency generation is tools/c2hs/c2hsLocal.deps, and the files 
generated by chsDepend.  As long as those are present, and (fairly close 
to) correct, the makefile should update them and any other out of date 
dependency files before proceeding with the rest of the build.

Now, I think I neglected to mention what the purpose of all this was, 
otherwise I think we'd be in more of an agreement :)  Initially I just 
wanted to clean up the makefile, but I then realized with a few small 
other changes, I would probably be able to get parallel builds working.  
And I did!  My current build tree works with make -j4 on both my linux 
amd64 system, and my mac.  (It doesn't work in windows, but I'm pretty 
sure it's a bug in the version of make I'm using on.)  I'll go ahead and 
pushed the patches so you can test them; if you're still not convinced, 
I promise I'll change everything back to the way it was :)

Pete