All objects and dependency files are in a separate directory hierarchy which mirrors the source hierarchy.
As I mentioned in my other reply, I'm still not sure if I'll do anything further to protect against this. Thanks, Greg. On Tue, 2005-04-12 at 10:50, Noel Yap wrote: > IMHO, dependency files, as with other generated files, ought to be built in a > directory structure separate from the source directories. If this were done, > one /would/ protect against _accidental_ erasure of the dependency files (no > mortal should be > meddling in the build directories). > > HTH, > Noel > > Greg Kilfoyle wrote: > > > Hi, > > > > 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? > > > > Cheers, Greg. -- Greg Kilfoyle <[EMAIL PROTECTED]> _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
