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

[Andrew Suffield]

On Fri, Sep 03, 2004 at 02:33:51PM +0200, Jan Hudec wrote:
> > > 1) There is no way to tell make, that though it ran a rule, the rule
> > >    didn't change anything. Thus the objects that depend on things built
> > >    by recursive make are always rebuilt.
> > 
> > Here's the way that doesn't exist:
> > 
> > foo.o: foo.c
> > 
> > foo.so: | foo.o
> > 
> > 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.

> > > 2) The headers have to be checked by each invocation of make. Since
> > >    we had many headers, included by each other quite extensively, the
> > >    dependency-checking was significant.
> > 
> > That's strange, and doesn't make any sense. This is what disk caches
> > are for. I'd have investigated in more detail; the scenario you
> > describe is not supposed to occur. stat()ting the same file twice in a
> > row should not take noticably longer than stat()ting it once.
> > 
> > I've seen plenty of projects with large numbers of cross-including
> > headers and I've never seen a problem like you describe here. So I
> > suspect there was something strange going on with your makefiles.
> 
> It's not really in a row. And well, it was the overhead of calling make
> as a whole. The makefiles were all quite large and they all used
> wildcards and funny stuff like that.

Aha. Now that sounds more familiar. I'm betting that the real problem
was in the evaluation time of the "wildcards and funny stuff". That
stuff can be quite slow, and is probably the single most frequent
cause of slow makefiles. There are a number of ways to tackle this
problem, while retaining make recursion. It's a classical make
optimisation problem, and you just picked one of many approaches.

> 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.

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.

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

signature.asc
Description: Digital signature