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

[Jan Hudec]

On Fri, Sep 03, 2004 at 13:49:22 +0100, Andrew Suffield wrote:
> 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

I have read the info and I don't see how to use this to achieve the
result I want.

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

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

Ok. Looking again. And finding out, that the inclusive make does exactly
the same amount of wildcarding, as the recursive! Both the recursive and
inclusive build system include a "rules.make" file, which does all the
globing. And the rules.make files for the inclusive and recursive make
were quite similar, except that the inclusive has various prefixes all
around the place. Even the rules are actualy loaded for each directory
separately in the inclusive make, because they are the:
$(sources) : %.o : %.c
rules. What is only included once in the inclusive make is the autoconf
output (and it has some 25 variables + 1 conditional only) and another
init file of about the same size (+ cleaning rule).

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

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

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>

signature.asc
Description: Digital signature