lkml.org 
[lkml]   [1999]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] new makefile for fbcon
Dominik Kubla wrote:
>
> 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%...).

How do you think the kernel gets onto a new platform, without
cross-compiling features? But, building outside the source tree has
nothing to do with portable Makefiles.


> 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

They are related in that we rely on GNU-isms in GNU tools throughout the
compiler. GNU makefile'isms. GNU gcc'isms. GNU binutil'isms.

IMHO it is far more productive, and often easier, to port the GNU
toolchain to a new platform, than to make the kernel sources use a wider
array of _build tools_.


> a) Can not use better-optimizing compilers from hardware vendors (like Compaq
> on Alpha systems or possibly SUN on SPARC)

This is a red herring. The parts of the kernel which need the most
optimization are generally hand-optimized anyway. Recompiling POVray
with the Compaq Alpha compiler buys you alot. I'll bet recompiling the
kernel with Compaq Alpha compiler would make it _slower_ due to the lack
of certain gcc'isms.


> b) Can not verify that a certain behaviour is compiler-related without
> analyzing the generated assembler code (a tedious task at best!)

Oh come on. This could apply for any number of situations with any
number of compilers. Debugging is all about reducing variables, and the
compiler will always be one of those variables.


> > 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).

What are you talking about? People build outside the source tree with
auto{conf,make} packages all the time. Besides, that too is a red
herring. I'm talking about an automake-like system for building
Makefiles. automake-like, not automake. Not autoconf.

And GNU automake is very actively maintained. Check out the latest
version of CVS even.


> 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).

Having a portable Makefile (the subject of this thread) has nothing to
do with building outside the kernel source tree. It shouldn't be too
hard to set that sort of thing up, and that would definitely be useful
to the distribution makers (like MandrakeSoft :))

--
Jeff Garzik | Just once, I wish we would encounter
Building 1024 | an alien menace that wasn't immune to
MandrakeSoft, Inc. | bullets. -- The Brigadier, "Dr. Who"

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.476 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site