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

[Andrew Suffield]

On Sun, Aug 29, 2004 at 11:19:53AM +0200, Jan Hudec wrote:
> On Sat, Aug 28, 2004 at 22:14:12 +0100, Andrew Suffield wrote:
> > On Sun, Aug 29, 2004 at 06:41:39AM +1000, Zenaan Harkness wrote:
> > > Since I only came on the list about 8000 messages ago (which actually
> > > isn't that long really), and since James recently mentioned about
> > > "getting ones build system right", is there a link that people get
> > > pointed at to describe "the right build system"?
> > 
> > You might as well ask for "the right program". Constructing a build
> > system, *even using tools to simplify the process*, is a programming
> > problem that requires every bit as much skill and effort as
> > constructing a program.
> > 
> > 99% of lousy build systems are that way because they didn't receive
> > either. Ones based on auto* are compounded by the problem that the
> > author probably hasn't read the manual for the tools he is using; most
> > autoconf scripts are an exercise in cargo-cult programming.
> 
> I have an uneasy feeling that automake is specificaly designed for cargo
> cult programming. Whenever I try to do something clever or nonstandard
> I find myself replicating various parts of it's functionality.

I've never found that to be the case. But I have seen an awful lot of
people doing it needlessly.

> > > Fastdep (now in Debian sid), pointed me to the paper Recursive Make
> > > Considered Harmful:
> > > http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html
> > 
> > I hate this paper. It's snake oil.
> 
> I can tell one thing. I have a real world experience that inclusive make
> is faster and more reliable.

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.

The paper claims "There exist no cases where this method does not work
better". That's pretty outlandish.

A useful paper would have explored the scenarios in which one method
was better than the other.

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

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

signature.asc
Description: Digital signature