Re: [PATCH] new makefile for fbcon

Dominik Kubla (dominik.kubla@uni-mainz.de)
Sat, 13 Nov 1999 01:12:07 +0100


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/