On Thu, 7 Sep 2000, Michael Elizabeth Chastain wrote:
>> However, NO ONE has taken the time (I'm talking weeks of doing nothing
>> but screwing with Makefiles) to completely rewrite the build system.
>
>I have done exactly that.
And how much did RedHat pay you to do it?
>And I gave you the URL. You want to read it, or you want to keep whining
>that "NO ONE" is doing the work I am pointing you directly to?
What you point at and what's in the kernel tree still isn't complete. And
it's still a load of hackish crap. Rules.make is still an enormous pile
of goo -- highly condition and hard to follow. (Not that it's ever been
anything else.) Some of the hackishness is inescapable -- flag tracking
for one.
The ugly "ifeq ... endif" blocks in Makefiles need to be gone. All of them.
Everywhere. NO exceptions.
The additional (redundant clone) build rules need to be gone.
The "boilerplate" sections should be in one place, not cloned in every
Makefile. Actually, they shouldn't be necessary if the "old-style" is
gone.
I should be able to cd to any directory anywhere in the tree and build
anything. (That's always been a toughy.)
Shall I continue?
>> What's the point in making processors faster if everyone just
>> wastes the increase being "correct and simple"?
>
>I've also benchmarked my Makefiles against the stock kernel Makefiles.
>The "correct and simple" Makefiles run in 1/2 the time.
Simple corrections to a few places can account for 90% of this speed up simply
by correcting the erronious recompliations -- and yes, I fixed those in my
source tree long ago. Optimizing the Makefiles certainly make them easier
for a human to deal with but doesn't make order of magnitude differences to
"make". Try running your benchmark with "make -n" to see the speed of the
Makefile processing instead of compilations.
(If you really wanna speed up make, then disable all of it's implicit rules
and suffix mapping.)
>Honestly, it's like talking to a wall here. Rick[y], you don't know what
>you're talking about, and you show too much unwillingness to learn.
>I'm not interested in your prejudices any more.
Oh, I know more than you think I do. Perfection is a hard thing to find.
Finding anyone who knows how to actually write a Makefile is just as hard.
(Just because I tend to keep my toys to myself is my business.)
It is my opinion that one should not tweak, hack, evolve, fix, or even
otherwise look at the spooge that has served as the build system for years.
Burn it to the ground, bulldoze the asses out of the way, and actually
_design_ a _new_ system. Enumerate what functions and requirment there are
and build 'em. No "backwards compat."; no hold overs from the days of the
Roman Empire; no "new way" and "old way", simply "THE way".
Take a lesson from Mother Nature: Forest fires are a Good Thing (tm)
--Ricky
PS: How the hell did we go from complaining about the "stubby modules tree"
to relative speeds of make? I stand by my original comments: one file
per directory is no better (worse even) than all files in one directory.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:31 EST