Re: [Gnu-arch-users] Build System links/ recommendations

[Andrew Suffield]

On Fri, Sep 03, 2004 at 03:59:01PM +0200, Jan Hudec wrote:
> > > > The behaviour you describe is what you normally want. In the strange
> > > > scenarios where you don't want cascading rebuilds, you use an
> > > > order-only prerequisite, which behaves like "make foo.o && make foo.so".
> > > > 
> > > > I can't imagine how you think monolithic makefiles are different
> > > > here. The cascade behaviour is the same either way. The way to turn it
> > > > off is also the same.
> > > 
> > > Um, we failed to find that in the GNU Make texinfo documentation. But it
> > > may be.
> > > 
> > > The cascading behaviour is NOT the same. In the recursive makefile, the
> > > binary was always linked, even if nothing at all was touched (because
> > > the first level invocation didn't know dependencies of the library and
> > > had to call the second make).
> > 
> > That doesn't matter. If the rule for any prerequisite is run, then the
> > target rule is run, regardless of whether the prerequisite was updated
> > by its rule or not.
> > 
> > The fact that a monolithic makefile has both rules in the same DAG
> > does nothing to change this behaviour.
> 
> But the monolithic one knew enough not to run it.
> 
> Recursive make:
> 
> make foobinary
> - considering foobinary
> - considering foolib/foolib.a
> - will make foolib.a (because it does not know prerequisites, so it
>   can't decide, so it has to run the recursive make)
> make -C foolib foolib.a
> Entering foolib
> Nothing to be done for foolib.a
> Leaving foolib
> - will make foobinary (blindly, it had run a rule for a prerequisite,
>   though the prerequisite is still older than the target)
> ld $(LDFLAGS) -o foobinary $(fooobjs) foolib/foolib.a
> 
> Monolithic make:
> 
> make foobinary
> - considering foobinary
> - considering foolib/foolib.a
> - considering $(foolibobjs)
> - nothing to be done for $(foolibobjs)
> - nothing to be done for foolib/foolib.a
> - considering $(fooobjs)
> - nothing to be done for $(fooobjs)
> Nothing to be done for foobinary

Ah, I see what you've done here. Anyway, here's how to do it with
recursive make:

foobinary: | foolib/foolib.a

foolib/foolib.a: 
        $(MAKE) -C foolib foolib.a

Which should have been a single | added to the recursive makefile at
the appropriate point. You needed to tell the recursive makefile that
the recursion rules were recursing and not building.

> > > Anyway: Would you agree with a sumary, that:
> > >     * For mostly independent parts of a project, ie. source vs. doc vs.
> > >       l18n stuff etc. recursive makefiles perform better (and are easier
> > >       to maintain). The same usualy holds for sources of libraries.
> > >     * For things that depend on each other a lot, single makefile does
> > >       better job.
> > > ?
> > 
> > Not without evidence. The former is probably true. The latter is
> > merely possible, and I expect there are scenarios where it doesn't
> > hold. I'm reasonably confident I can construct a pathological case
> > where it doesn't.
> 
> So go ahead and constuct it.

Better things to do with my time. Imagine a classical tree full of
libraries and binaries, where each one has a fiendishly complex DAG
that's completely internal. Sooner or later the monolithic makefile
will waste huge amounts of time chasing the wrong branches in the DAG,
which could never actually be needed.

The boundary case here is unknown.

> > Again, a useful paper would be one which actually investigated these
> > scenarios and tried to figure out what the determining factors and
> > boundary conditions were. Of course, that could prove something the
> > author doesn't like.
> 
> I am not going to write a paper about it and I don't think the paper
> "Why recusive make is considered harmful" is briliant. I am trying to
> come up with a useful advice in what is likely to work better.

I don't think you can accomplish it through speculation. Only research
will find out which is better; speculating merely (eventually) reveals
that there are many possible approaches with different performance
characteristics, which are difficult to predict.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature