"Philip Guenther wrote:"
>
> Looking backwards, this rule from your top level makefile:
>
> > $(INF_DIST_SVCS_OBJS): $(DIRS)
>
> seems bogus, given that $(INF_DIST_SVCS_OBJS) is a list of objects in
> directories _below_ the list of directories in $(DIRS). The top level
> make may recurse, then on popping back out see that the *SOURCE
> DIRECTORY* didn't change, and thereby decide that the object must not
> have changed.
OK, the fix ended up being fairly minor to implement. We replaced the
$(DIRS) target with:
$(INF_DIST_SVCS_OBJS): $(INF_DIST_SVCS_SCRS)
@$(SET_E); $(MKDIR) $(@D); cd $(@D)/.. && \
PATH=$(PATH) "$(MAKE)" $(OBJDIR)/$(@F)
Had to create another macro $(INF_DIST_SVCS_SCRS) which is defined as:
INF_DIST_SVCS_SCRS = $(foreach DIR,$(DIRS),$(wildcard $(DIR)/*.cpp))
We still need to had a filter capability to the macro yet. Testing has
shown this to be solid and you get the message that your object file is
up to date for each object file that does not need to change.
>
> It looks me like your makefile is misleading make.
>
> Can you give examples of the output of make when this stuff *isn't*
> working? Preferable minimal, of course, where only a single source
> file was changed/recompiled, showing how make failed to rebuild
> everything that it you wish it would, and then the output of the
> second make invocation that builds the missing piece?ou
>
>
> I don't trust dependencies on directories; you have a dependency on a
> directory WHOSE CONTENTS AREN'T BEING CHANGED. That raises florescent
> red flags to me.
>
>
> Philip Guenther
>
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
