Messages in this thread |  | | From | Jim Nance <> | Subject | Re: source dependencies cleanup? (fwd) | Date | Wed, 4 Dec 1996 23:07:22 -0500 (EST) |
| |
> 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: /usr/tmp/builtin/arch/i386/boot/zImage /usr/tmp/modular/arch/i386/boot/zImage
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 comments?
Jim
|  |