RE: Advanced Auto-Dependency Generation

[Alexander.Farber]

Hi,

I'm not a gmake expert at all and often struggle to understand it.

But my suggestion is: if you want so much, that the .d (actually .P) 
files get regenerated in cases they get deleted - then you obviously 
need a rule for them, like the one listed in "Basic Auto-Dependencies".

Also what I dislike about the trick listed in "Advanced Auto-Dependencies"
is that it doesn't work for parallel builds: there is no rule for .P files.
A process includes a .P file while it is still being generated by another 
process and the build fails (we use pvmgmake here).

Regards
Alex 

> On Tue, 2005-04-12 at 09:36, Greg Kilfoyle wrote:
> > 
> > I have implemented dependency generation based on the information from
> > this web page: http://make.paulandlesley.org/autodep.html
> > 
> > It works great, but my implementation has one serious drawback that I
> > don't see covered ... maybe I just missed something.
> > 
> > Let's say I have just done a complete build and everything is up-to-
> > date. I then manually remove a dependency file for a particular .c file
> > and update a header file that the .c file is dependent on. 
> If I then run make, the .c file is not rebuilt.
> > 
> > I had a depclean target in our environment, which I removed because of
> > this problem. But I can't protect against someone 'accidently' removing
> > a dependency file.
> > 
> > The following is a brief version of our .c->.o rule:
> > 
> > $(objs): $(objdir)/%.o: $(srcdir)/%.c
> >         gcc -c -MP -MD$(basename $@).d -MT'$@ $(basename $@).d' -o $@ $<
> > 
> > ...after this rule there is an include of the dependency file(s) using
> > '-' so it can silently fail.
> > 
> > Is this something I've failed to account for in my implementation or
> > something that is missing from the proposed implementation method?
> >