> Any changes that allow distributors to simultaneously build kernels for
> different architectures and/or configurations from the same source-tree
> will be jumped on by those distributors ...
ftp://ftp.shout.net/pub/users/mec/dancing-makefiles-2.3.15
> regardless of the change in size
typical Makefile shrinks to 25% of its former size
> Note that implementing such a capability in the kernel makefiles has
> certain implications, eg one would have to move include/asm-<arch> to
> <arch>/include/asm and get rid of those pesky symlinks.
"Pesky symlink" is right on target; I hate that symlink!
But Dancing Makefiles already handle it correctly with no changes
in .c or .h files. The key is: -I$(dir-target)/include and the
asm symlink lives in there.
> Next one has to think about autoconf.h and version.h which have to be
> created in the obj directory and not the src directory (speaking in
> BSD terms here).
You are right again. -I$(dir-target)/include works well here.
It's followed by -I$(dir-source)/include, so the target tree
functions as an overlay layer with just a few files in it
(autoconf.h, compile.h, version.h, asm symlink).
> ... if done with a good design, the resulting Makefiles could be smaller
> in size and faster in terms of procesing time.
They *are*. I'm talking about drivers/net/Makefile going from 1000
lines to about 200, and overall "make vmlinux" running 30% faster
when there is no work to do.
Then there is the #1 advantage: correctness. I can just patch over
any part of the tree and the dependencies auto-update correctly and
so on.
Too bad my stuff is not feature-complete.
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/