On a smaller config (full config takes too long when single threaded).
kbuild 2.4:
make oldconfig dep bzImage modules 6:25
make bzImage modules (no changes) 0:22
kbuild 2.5:
make oldconfig installable 4:45
make installable (no changes) 0:16
>You seem to have written an awful lot of code just to build something.
>Perhaps it would have been easier to just replace make completely with a
>custom builder @)
Would not have helped. Apart from all the people who complain about
needing extra tools to build the kernel (remember the Python wars for
CML2?), the kernel build has some really nasty requirements :-
* Most dependencies are not listed. kbuild has to work out which
sources depend on which headers, sometimes sources include other
sources.
* 2,200+ config options, each of which can affect as little as one file
or as much as the entire kernel. kbuild has to work out what each
config option affects.
* Changing a config option must only rebuild the affected targets, not
the entire kernel.
* Changing a command must rebuild only the affected targets, not the
entire kernel.
* You can change a command from the makefile, from the command line or
as a side effect of changing a config option.
* After applying a patch, kbuild must work out what has changed and
only rebuild the affected targets. Even if the patch changes the
dependencies or commands!
Most of the work of kbuild 2.5 is tracking all the special cases, as is
a lot of the code in kbuild 2.4 Rules.make. Any custom builder would
have to do the same amount of work and tracking, so replacing make by
another tool would not save anything. I looked at the various make
replacements like scons, but none of them were ready for the
complexities of kbuild.
-
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/
e 2.0 is available"