Re: Advanced Auto-Dependency Generation

[Alexey Neyman]

Hi,

I think the following Makefile does just what you want:

========================
FILES   = a.c b.c
OBJS    = $(addsuffix .o,$(basename $(FILES)))
DEPS    = $(addsuffix .d,$(basename $(FILES)))

%.d %.o: %.c
    gcc -c -MT '$*.o $*.d' -MD -MF $*.d -o $*.o $<

prog: $(OBJS)
    gcc -o $@ $^

all: prog

clean:
    rm -f $(OBJS)

distclean: clean
    rm -f $(DEPS)

ifneq ($(MAKECMDGOALS),distclean)
sinclude $(DEPS)
endif
========================

Hope that helps,
Alexey.

On Wednesday 13 April 2005 13:44, address@hidden wrote:
> 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?
> > > 
> 
> 
> _______________________________________________
> Help-make mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-make
> 

-- 
Heavily laden, it rocks and weaves, but does it turn over?
                        -- Pkunks, SC2