bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Intermittent parallel make rebuild failures


From: David Highley
Subject: Re: Intermittent parallel make rebuild failures
Date: Fri, 8 Oct 2010 09:04:43 -0700 (PDT)

"Philip Guenther wrote:"
> 
> On Thu, Oct 7, 2010 at 9:22 AM, David Highley
> <address@hidden> wrote:
> ...
> > Let us just cut to the essence of the issue we are running into, how do
> > target prerequisites get processed in version 3.81 of make?
> >
> > Example:
> > $(LIBRARY): $(INF_DIST_SVCS_OBJS)
> >
> > $(INF_DIST_SVCS_OBJS): $(DIRS)
> >
> > $(DIRS):
> >
> > .PHONY: $(DIRS)
> >
> > With parallel building how does the macro $(INF_DIST_SVCS_OBJS) get
> > evaluated before the target $(DIRS) is done? Is there a method to stop
> > this other than turning parallel building off?
> 
> Have you read the info pages section "How `make' Reads a Makefile"?
> In it, it explains that variables in targets and prerequisite lists
> are expanded immediately when the rule is read during the parsing of
> the Makefile.  So, *before any targets have been built*,
> $(INF_DIST_SVCS_OBJS) will be expanded twice during the parsing of the
> above Makefile snippet, once when the $(LIBRARY) rule is parsed and
> once when the $(INF_DIST_SVCS_OBJS) rule is parsed.

Yes I know the normal order of processing of includes, macros, and
targets. I will say that I have some that use $@ which is only defined
when the target is executed can work.
> 
> The -j option has no effect on that, so I don't understand your last
> question above.  Or are you saying that this makefile is part of a
> recursive make setup, so that it might be read multiple times, the
> earlier of which could affect the latter of which?

OK, the behavior has been very miss leading in this case. The real issue
is that there is no knowledge of the source files at the upper make
level yet we are rolling all the lower level created object files
into a larger library. Would not need to do this if on UNIX/Linux
platforms you could stuff multiple libraries into a collection library
and get the linker work right. This does work on Windows, but we need
solutions that work across a wide array of platforms.

The behavior is such that non parallel builds work every time. If several
object files change then it seems to work. If you touch only one source
file and build then it will fail most of the time.

If you add $(INF_DIST_SVCS_OBJS) to the .PHONY: target it will work
every time, but unfortunately it will relink even if no object file
changes. If you add an order dependent prerequisite "| $(DIRS)" to the
library target it has no effect. So I'm still working on the right
solution.

By the way I hope to make available our build process in the near
future. I have been working on documenting it and hope that others may
find it useful, educating and can provide feedback with their ideas for
making it better. It has proven to be light weight and easy to bring up
on new projects.

> 
> 
> Philip Guenther
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]