Re: Use move-if-change on macro_list dependency

[Geoffrey Keating <geoffk at apple dot com>]

On 17/11/2004, at 3:08 AM, Nathan Sidwell wrote:

> Geoffrey Keating wrote:
> > On 16/11/2004, at 4:31 AM, Nathan Sidwell wrote:
> > > I received the attached patch from Jon Grimm, jgrimm2@us.ibm.com --
> > > I've added the changelog. It does fix the problem I am seeing, and 
> > > seems
> > > good to me.
> > >
> > > tested on powerpc64-unknown-linux-gnu with -j4 bootstrap
> > Does this really fix the problem, or does it just permute the 
> > Makefile and cause the underlying problem to be hidden?
> > (If it does fix the problem, could you explain how?)
>
> All the other uses of move-if-changed in the makefile use the stamp 
> file
> idiom.  We're using recursive makes and move-if-changed is causing
> the child makes to be lied to, as the file time stamps no longer 
> reflect
> the rebuilding wavefront.  The stamp idiom makes sure the rebuild 
> wavefront
> is accurate.  the child makes will percieve macro_list as out of date
> wrt stmp-macro_list, but the rule to rebuild that causes no change to
> the file system, only changes the child make's internal state.

I've actually seen another report, from Dale, that having multiple 
sub-makes running inside the gcc/ directory causes other problems; he 
wasn't seeing anything to do with macro_list, he was failing earlier 
trying to build insn-recog.c (or some insn- file, anyway).  So I'm 
quite sure that this patch doesn't fix the problem it was claimed to 
fix, which is that we have multiple copies of make trying to rebuild 
gcc/.

However, it may fix some other problem.  From the description above, it 
saves an exec() or two, at the cost of adding an extra rule; so it's a 
performance patch, or possibly an unperformance patch.

If, considering the above, you still think this patch is a good idea, 
it's OK to commit.

Attachment: smime.p7s
Description: S/MIME cryptographic signature