[lkml]   [1996]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: source dependencies cleanup? (fwd)

> This all works out perfectly well. Well... almost. The big advantage of the
> latter is that you scan b.h only once; gcc scans it twice. The big
> disadvantage is that you can't keep your kernel sources on a readonly
> partition.

Well you can't put the kernel sources on a ro partition anyway because
the .o files have to go into the directories with the .c files. This
would be something really nice to fix. At the time I created the
Rules.make file it was my intention to fix this. Unfortunatly having
a child consumed much more of my time than I though it would, so I have
not touched the Makefiles in about a year and a half, and all the neat
stuff I wanted to do has gone undone. As they say "The road to hell is
paved with good intentions".

As a partial atonment for my sin of not finishing what I started, let me
talk about what I wanted to do so we can get the ideas fleshed out in
case anyone wants to improve the make process. At least if there is some
vision of what we want the make process to look like, we can avoid doing
anything would be incompatable with that goal. At the time I was working
on the Makefiles, I thought it would be good if one could compile kernels
with different configurations w/o having one build destroy the .o files
from a prior build. For example, say I am working on a device driver for
the Nance-2000 omnipotent SCSI card. I want the driver to work both as
a compiled in component and as a module. Under the present setup it is
inconvinent to swith back and forth between the two because running make
config causes almost everything to recompile. Thus if I change the driver
and want to recompile 2 kernels, 1 modular, and one builtin, I am going to
have to recompile almost the entire kernel. The way I was thinking of
improving this was to have an optional variable which would be set on the
command line of make, which would cause all files created by the build
process to go into a seperate tree in the file system. Thus you could
then do:

make TOP_TREE=/usr/tmp/builtin zImage
make TOP_TREE=/usr/tmp/modular zImage

and all the files created by the build process, including the .config,
automatically generated includes, depedencies, and symlinks, would be under
TOP_TREE. In the above cases we would have kernels in:

A side benifit of this scheme is that the kernel source can be on read
only media since we never write anything to it. It is fairly easy to
implement a scheme like this, but its tedious because you have to keep
recompiling the kernel. Hopefully I have made it clear what I was trying
to do. Sometimes I have difficulty explaining things. Anyone have any


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