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/