All fixed in kbuild 2.5.
>I personally don't care about correctness in the sense of getting "make"
>doing everything for you regardless of what you changed, I'm fine with
>some "make distclean" forced checkpoint after PATCHLEVEL changed etc...,
>you said infact full compile is needed sometime, not to tell about
>kernel configuration.
Strongly disagree. One of the biggest problems with kbuild is the user
who applies a patch and expects the kernel to automatically rebuild
just the bits that are affected. We must not rely on every user doing
make distclean or mrproper after applying a patch, we know that does
not happen, resulting in inconsistent kernels. If you want to do a
complete recompile after a patch that is your choice, but we cannot
rely on the entire user population doing that. kbuild must be
automatic and correct.
>One good example is the mkdep hack, it's far from correct: the header
>dependences is nearly random. We cannot trust it unless we remeber
>every user included us (one more reason I'm used to full recompiles),
Absolutely agree. The design assumption for mkdep is that the source
and/or .config do not change after make dep. That might have been true
once but with several kernel trees, separate arch patches, separate sub
system patches and compiling for multiple configurations it is not true
now. kbuild 2.5 completely redesigned the dependency tree and gets it
right!
However we are getting off the original patch which removes spurious
compiles from the existing system.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/