mec> This is correct. 'make dep' needs to visit $(ALL_SUB_DIRS) so that if
mec> you change your configuration, the dependency files are still correct.
martin> I disagree. All that fastdep does is generate a .depend file
martin> in *that* directory. If that directory is not recursed through
martin> by the main compile or module compile, that file is never used.
Read what I wrote. "If you change your configuration." That's why the
dependencies span the entire tree: so that if the user turns on a new file
system or a new network protocol, they don't have to run 'make dep' again.
The user doesn't know which options correspond to which directories.
If "make dep" visits only the subdirectories currently in use, then the
user has to run a "make dep" after every configuration change. My way,
they don't (unless they have CONFIG_MODVERSIONS on, which introduces a
whole set of gotchas).
mec> scripts/mkdep is super fast, and it works properly even if the source
mec> file includes header files that don't exist on your architecture, like
mec> <asm/prom.h> in drivers/macintosh/adb.c.
martin> Super fast huh? It takes 90 secs to do the dependancies. That
martin> about 10% of the total compile on my machine for everything.
On my machine, it's 3%, by actual measurement. I trust my measurements
more than yours.
mec> You only get a problem if you turn CONFIG_MODVERSIONS on. Then it
mec> tries to genksym files that aren't in your configuration and cpp
mec> gives error messages. But 'make' ignores the errors so 'make dep'
mec> staggers to completion.
martin> genksyms? where? The output of make dep doesn't mention
martin> the word genksyms, module or anything like that anywhere.
You really have a problem reading what I write. Do I need to use
html or something to get your attention?
<clue>
<bold>
<blink>
if you turn CONFIG_MODVERSIONS on
</blink>
</bold>
</clue>
Do it. Turn it on, capture the output of "make dep", and grep for
genksyms.
martin> Just for arguments sake, I actually implemented it, and it
martin> cut the dep time down to 38 seconds,
Color me unimpressed. By your own figures, you cut your build time
by 6%. But you broke the dependencies that the user needs in case
of reconfigration.
Hey, if you want fast broken dependencies, just don't run make dep
*at all* and your kernel will still build. The first time.
(Unless you turn on CONFIG_MODVERSIONS). That gives more speed-up
than your patch, and it's just as broken with regard to configuration
changes as your patch.
Michael Elizabeth Chastain
<mailto:mec@shout.net>
"love without fear"
-
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/