Here are a few points: 1. For the code that I'm supporting includes are rarely changed.
2. By default I will always rebuild dependencies (the all rule I showed). For this case I thought about it for a few minutes I don't think dependencies will become out of date if auto-remaking doesn't occur (as the author pointed out for in the advanced case), can you give me a counter example? What I'm doing is very similar to the Basic Auto Dependencies case from the article. Plus I'm not using gcc for my final compiler and can't combine the dependency creation with compiling. 3. I want to have a nodepend rule that will not rebuild dependencies in order to save time (this won't be the default so developers will have to look into the make file and its comments to understand the consequences). Is it possible to do what I want? Also, though it seems to be related, I don't think autoremaking answers my second question. Why does rebuilding running "make a.o" also rebuild a.d? a.o doesn't depend on a.d. On Wed, Sep 23, 2015 at 12:24 PM, Paul Smith <psm...@gnu.org> wrote: > On Wed, 2015-09-23 at 12:15 -0500, John Westing wrote: > > So when an include make file gets modified make restarts the original > > make file? > > Correct. > > > For efficiency I don't want to always create the dependencies, that's > > why I did it this way. > > I don't understand what you mean by this... for efficiency (of which, if > you use the advanced method, you gain almost none) you're willing to > have outdated dependency information and thus incorrect builds? That > doesn't seem like a winning trade-off to me :). > > > Is there anyway to disable remaking? > > No. There could be some workaround available to keep make from > remaking, but you'll need to describe to us what you really want to > happen, in detail. When should these .d files get updated? > >
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
