Messages in this thread | | | Date | Sat, 13 Nov 1999 02:00:17 -0600 | From | Michael Elizabeth Chastain <> | Subject | Re: [PATCH] new makefile for fbcon |
| |
Oh man, it's hard to control myself ...
> 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/
| |