Re: Intermittent parallel make rebuild failures

[David Highley]

"David Highley wrote:"
> 
> "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.

Well, as is the case with most software development we still had issues.
The real issue seems to be the early evaluation of prerequisites and also
not having enough knowledge of the code at the upper level make
location. So while the fix ended up being minor the discovery was a long
process. We ended up adding a recursion at the top level:

all: $(DIRS)
        $(SET_E); PATH=$(PATH) "$(MAKE)" $(LIBRARY)

So in the end we removed the new macro that only provided knowledge of
the body files and not the header files so it was still an incomplete
solution.

I did get a synopsis of our build process pushed to the web with some
overview documentation. We would appreciate any feedback and we hope
that others can find useful working examples from this build process.
This build system and our applications work across Solaris, Linux,
Windows, and VxWorks. While the newer WindRiver tool sets are a little
easier to work with it still requires some separate build process when
you are constructing the application image. If you are just building
support libraries it can be done like other platforms. All of our builds
use relative paths and require Cygwin for the Windows platform, and for
the VxWorks builds as the tool set is hosted on Windows. All of our
compilers are checked into ClearCase, but the build process is
independent of ClearCase except for how we build version identification
into the build products.

http://www.highley-recommended.com/make_process/index.html

> 
> > 
> > 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-make
>