Re: source dependencies cleanup? (fwd)

Joshua M. Thompson (invid@optera.com)
Thu, 5 Dec 1996 00:22:06 -0500 (EST)


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