Re: build system rules & algorithms

[Mike Shal]

On 6/11/09, grischka <address@hidden> wrote:
> Mike Shal wrote:
>
>
> > For some hard numbers, my
> > machine takes 17s to run make in an already-built linux kernel tree.
> > Just doing a 'find . | xargs stat > /dev/null' only takes 2.6s though,
> > so I would guess the remaining ~14s are mostly for parsing Makefiles
> > and processing the DAG.
> >
>
>  Careful with conclusions from "hard numbers".

Fair point :)

>
>  Consider that in comparison to "17s to run make in an already-built linux
>  kernel tree", TCC needs ~15 seconds to COMPILE AND LINK the entire linux
>  kernel tree -> http://bellard.org/tcc/tccboot.html.  That
> at least shows
>  that no program would spend that "~14s" just to read some Makefiles or
>  loop over some linked lists (i.e. "processing the DAG").

I've never heard of TCC - I'll have to check it out! Though my point
was merely that make is doing *something* during those 17s, none of
which is useful to me since no files have actually changed in the
kernel tree. The stat()ing is just a rough estimate of that portion of
make's execution time. Is there a better way to benchmark it to figure
out the bottlenecks?

>  After all GNU make is not "the reference implementation of an alpha build
>  system".  It is a piece of code with a long history with more going on
>  than just a few O(n) lookups.  You might find features like checkout
>  from RCS/SCCS version control via built-in rules which is obsolete stuff
>  since long ago, still everyone using GNU make today is paying for it with
>  maybe 80% of it's total CPU time, worldwide. (Try "make -r ..." to see
>  what I mean).

Yeah, I've seen some pages that document how to get rid of a bunch of
that built-in stuff (there were a few patterns you had to add to a
Makefile as well, if I recall correctly). Has anyone done benchmarks
on that to see what kind of overhead that actually accounts for?

>  Anyway, good luck with TUP, I'll try it out.  And waiting for your new
>  "beta CONFIGURE system", if any possible one that doesn't rely on
>  megabytes of unmaintainable shell scripts ... ;)

Thanks! I might want to leave the configure system to someone else, though :)

-Mike