Messages in this thread | | | Date | Sat, 13 Nov 1999 01:12:07 +0100 | From | Dominik Kubla <> | Subject | Re: [PATCH] new makefile for fbcon |
| |
On Fri, Nov 12, 1999 at 11:54:14PM +0000, Jeff Garzik wrote: > > Any solution which makes these Makefiles larger as a result of > portability changes will probably be frowned upon. Also, the kernel > relies heavily on gcc'isms. I doubt people really care that much about > having portable Makefiles. The kernel will be requiring the GNU > toolchain for some time to come...
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, regardless of the change in size of the Makefiles (besides: even if the Makefiles would increase a hefty 50% in size it would result in an overall increase of the kernel sources by less than 1%...).
Besides (ignoring for a moment that the use of gcc and gmake is _ABSOLUTELY_ unrelated) the fact that kernel can only be compiled with GCC has repeatedly been recognized by various people as contraproductive, since you
a) Can not use better-optimizing compilers from hardware vendors (like Compaq on Alpha systems or possibly SUN on SPARC) b) Can not verify that a certain behaviour is compiler-related without analyzing the generated assembler code (a tedious task at best!)
> If you really want portable Makefiles, we need to go to an automake-like > system which generates true, POSIX-portable Makefiles from Makefile.am > meta-makefiles.
Won't do you much good: autoconf (and the whole GNU build system) does not allow distributed use of a unified source tree (cygnus automake allowed that at one point, but is apparently no longer maintained).
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. 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). But these issues are resolvable and so far i have yet to see indications that this would bloat the kernel, to the contrary: if done with a good design, the resulting Makefiles could be smaller in size and faster in terms of processing time (note that gmake is typically slower than pmake and has a bigger memory footprint).
Yours, Dominik Kubla
- 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/
| |