Then I added one more driver.
kbuild-2.4 make dep + make bzImage ~7 minutes
kbuild-2.5 make installable ~2 minutes
So my conclusion was that one single change where *I* had to run
make dep made it worthwhile to shift to kbuild-2.5.
I know that *I* have to run make dep far more often than
all the kernel hackes - they know what they are doing in contrast.
With respect to kbuild-2.5 inclusion, I would vote for the distributed
configuration scheme that Linus et al. suggested a while ago.
[driver.conf that included makefile.in, configure.help etc.]
When kbuild-2.5 has been extended to support it, and the link-order
have been solved then it is due time for inclusion.
Jeff Garzik & Keith O. had some discussion about the link-order
problem a while ago, but at that point in time Keith stopped the
discussion whith the statement that he did not care about 2.5,
with reference to the refusual from Linus to accept among others
the LINK_FIRST - LINK_LAST patch.
I dunno what the conclusion on the link-order issue was.
What I read between the lines is that kbuild-2.5 should not only fix
the kbuild-2.4 bugs[*], but should also address the scalability issues
that Linus raised - before he accepts it.
[*] Bugs that I see, but kernel hackers are not hit by - because
they know what they are doing.
Personal I would like to see kbuild-2.5 included ASAP. Among other stuff
I like the compressed output during compilation.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/