Problem is that kbuild-2.5 needs to be split up for inclusion in the 2.5 kernel.
So my suggestion is that in a first step the Makefile.in in each directory could be parsed to the existing form of Makefiles[*], with the rest of the build system staying the same. This Makefile.in -> Makefile (per directory) parsing could be done as first step of "make bzImage" in the existing kbuild-24. This way we could have the new Makefile.in syntax in quite soon. The change from "Makefile" to "Makefile.in" in each directory can be done slowly during a few kernel releases (and so it's not necessary to have the 24/48 hour "nothing else happens"-period). After this first step (which would eliminate the need for "kbuild-common" and "kbuild-$arch") the kbuild-core could be targeted for splitting up so that it can be included in small pieces, too. So I'm not arguing for recursive Makefiles - it's just a suggestion on how to break the kbuild patch up for inclusion in the 2.5 kernel. Dominik Note[*]: needs not to be 100% equivalent, of course, just the result needs to be the same. "Difficult" current Makefiles which need complicated commands in the new Makefile.ins could be left out at first (again: step-by-step!) On Fri, May 24, 2002 at 06:14:23PM +1000, Brendan J Simon wrote: > I'm not quite sure what you are saying about coverting the Makefile.in > files to Makefiles. If you mean having a toplevel Makefile that > recursively calls the subdirectory Makefiles then forget it. This is > really bad as you effectively end up with lots of subprojects with > interdependencies that are generally incomplete. There is an excellent > short paper written by Peter Miller explaining why recursive Makefiles > are considered harmful. In summary, it gives the developer the > impression (and a false sense of security) that the build system will > accurately rebuild out of date files, but in reality it may not. The > paper is called "Recuresive Make Considered Harmful" and you find it at > http://aegis.sourceforge.net/auug97.pdf > > I apologise if I have misinterpreted your suggestions/statements. > > Brendan Simon.
msg01472/pgp00000.pgp
Description: PGP signature
