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

[Jan Hudec]

On Sun, Aug 29, 2004 at 12:18:24 +0100, Andrew Suffield wrote:
> Taken alone, that statement embodies the sort of flaw the paper has.
> 
> It's *easy* to show "There exists at least one project where this
> method works better". I can construct a pathological case to
> demonstrate that with little effort.

Yes, our project was kind of pathological case.

On the other hand, the inclusive make should never (provided it's
written reasonably) do worse, that recursive one.

> > We wrote a school project. It was not big, but it had a part in
> > userland, part in kernel, part for windows and parts that were compiled
> > for more than one part (the windows part had it's own build system for
> > MSVC++ though).
> > 
> > First we had standard recursive makefiles (hand written GNU makefiles). 
> > It was slow, it kept relinking it all the time (because the recursive
> > make was considered a change, though it wasn't) and we had problems with
> > things not getting rebuilt several times.
> > 
> > Then I rewrote the whole system for inclusive make (hand written GNU
> > makefiles again). It was faster by an order of magnitude and reliable.
> 
> This sort of story is the reason why that paper has become so
> popular. There's a problem with it:
> 
> You replaced a broken build system with a less broken build system,
> which coincidentally happened to use a monolithic makefile.
> 
> You don't really have any way to know *which* changes mattered. As a
> general rule, whenever you rewrite a broken build system, it will get
> faster and better.

Yes, we DO know, at least partialy. We identified two problems, that
could only be solved by inclusive make:

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.

   Thus recursive make is not suitable for building library and binary
   that depends on it. It's still OK for building two independent
   objects.

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.

   Thus recursive make is not suitable if sources built by different
   invocations of make have the same dependencies. It's still OK if they
   don't.

Summary: There is nothing wrong with recursive make for building
independent things, but all dependencies of each (real) target should be
built by single make invocation.

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

signature.asc
Description: Digital signature