If it makes it easier to get kbuild-2.5 into the kernel then I would support making the CML2 support available as a seperate patch/tarball for now. Once the dust has settled then it could be introduced later into the kernel tree.
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. Dominik Brodowski wrote: >CML2 seems to be unnecessary in kbuild-2.5. It's good to have >CML2-supporting code in the archive, but it's not really needed for current >versions. > >Keith: Do you have any plan on how to split kbuild-2.5 up in "manageable >pieces" Linus likes? Haven't really looked closely at the code, but could >the new-style Makefiles.in somewhat "easily" be transformed to the previous >per-directory Makefiles? Then one big advantage of kbuild-2.5, the new >_easier_ Makefile-syntax with its Makefile.in files, could be merged first. > _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
