On Wed, 2009-01-21 at 19:36 -0500, Peter Gavin wrote:
> 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.
Really? But if c2hsLocal and the dependency files are up to date, then
surely make wouldn't trigger the rule for building .deps files. I
haven't check this though. I'll just take your word for it :-)
> 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).
Well, they weren't updated before. So if you've got that now then that
is new. This is probably a good thing because this will help avoid the
build problems when people use darcs.
> 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.
No but you want the .dep files to depend on the source files such that
when the source files change, the dependencies are rebuilt.
What I tried to say about 'make foo.o' working is that in a clean tree,
the original Makefile would still build dependencies. If this works with
your version too, fine!
> 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).
Which error? (Just to make sure I'm with you.)
> 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 :)
Well, if you gain something then it's worth it. I'm just weary of
changing something that worked relatively well (with the deliberate
performance choice of only building dependencies once) to something that
is new, in particular, a few days before a release.
I'll try to test it. At the moement, you seem to have renamed a file but
without telling darcs:
config.status: error: cannot find input file: