Messages in this thread |  | | Date | Thu, 5 Dec 1996 00:22:06 -0500 (EST) | From | "Joshua M. Thompson" <> | Subject | Re: source dependencies cleanup? (fwd) |
| |
On Wed, 4 Dec 1996, Jim Nance wrote:
> 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
The example you cite is really just a symptom of a much larger problem with the configuration system in the kernel: specifically, all configuration data is in ONE place, namely autoconf.h, and thus a change forces a total recompile since you can't tell which files are really affected by that change.
Here's a case in point that happened just yesterday: I had a kernel that had PPP compiled as a module. I built this kernel a few weeks ago, and never did a "make clean" afterwards so the .o files were still lying around. Yesterday, I needed to have that same kernel with PPP in the kernel. By changing the configuration I was forced to rebuild the _entire_ kernel. This seems downright silly. Why should I have to recompile, say, the sound driver, just for a change in how PPP is configured?
Since the configuration scripts are already divided up by subsystem anyway, why not take the next logical step and create an autoconf.h-type file for each subsystem? We could do this in three steps:
(1). Create support on the Configure script for this. Have the data written out to both the old autoconf.h and the new individual header files.
(2). As time permits, start changing the various kernel source files to include the specific configuration headers instead of the global autoconf.h.
(3). Remove autoconf.h. Of course we may want to leave it just for compatibility. It doesn't particularly hurt anything.
Since autoconf.h is included automatically by config.h, I realize this will break some patches and modules not included in the main source tree. However, I think in this case the benefits greatly outweigh the problems.
As a side benefit, this may help clean up unnecessary dependancies in the kernel, because you'll have to specifically include the configuration headers for the subsystems on which your code depends.
I'm willing to start working on this if enough people think it's worth the effort. Of course I'd like Linus's blessing on this too since it's going to eventually involve patching pretty much every file in the source tree.
I'd be interested in anyone's thoughts on exactly how the configuration data should be divided. My first instinct is to create a config header for every place there is a Config.in file. Comments?
-- invid@optera.com | We are Grey http://www.optera.com/~invid | We stand between the Candle and the Star | Between the Darkness and the Light
|  |