Re: [kbuild-devel] remove CML2 support in kbuild-25
One small additional CML2-removal patch. Dominik --- linux-25-kbuild/scripts/Makefile-2.5.tmpFri May 24 09:55:44 2002 +++ linux-25-kbuild/scripts/Makefile-2.5Fri May 24 09:56:28 2002 -313,12 +313,8 # has completed. config_targets := xconfig menuconfig oldconfig defconfig config -ifeq ($(KBUILD_CML),1) - config_targets += randconfig allyes allno allmod -endif -ifeq ($(KBUILD_CML),2) - config_targets += ttyconfig advent treeconfig -endif +config_targets += randconfig allyes allno allmod + $(KBUILD_OBJTREE).config: $(filter $(config_targets),$(MAKECMDGOALS)) $(config_targets): $(filter autoprobe,$(MAKECMDGOALS)) msg01471/pgp0.pgp Description: PGP signature
Re: [kbuild-devel] remove CML2 support in kbuild-25
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/pgp0.pgp Description: PGP signature
Re: [kbuild-devel] remove CML2 support in kbuild-25
On Friday 24 May 2002 09:41, Dominik Brodowski wrote: 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. It's probably easier to do it the other way round: Make a user_command target (or similar) for each of the link_subdirs statements in the top-level Makefile.in in order to call the old kbuild Makefile in that directory. Then we can have seperate patches that convert parts of the tree from Makefile to Makefile.in and put the link_subdirs back. Of course, most of the new kbuild features will work only when everything is converted, but up to then you'll be able to compile with the new Makefile without losing any features in the intermediate steps. Arnd ___ 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
Re: [kbuild-devel] remove CML2 support in kbuild-25
Arnd: Your suggestion would mean that kbuild-2.5-core would have to get it as it is. Mine focuses on the kbuild-2.5-[common,$arch] to get in first as this seems to be the most time-consuming and frustrating to maintain. Dominik msg01474/pgp0.pgp Description: PGP signature
[kbuild-devel] Re: remove CML2 support in kbuild-25
[Dominik Brodowski] 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. I was going to say that this would not work at all because the paradigms for 24 and 25 are just too different ... but then I noticed that the vast majority of makefiles in the kbuild25-common patches are not really aware of the advanced kbuild25 features. Assuming someone were willing to write a parser to handle the common functions - select(), ifsel(), expsyms(), link_subdirs(), and a few others - a lot of Makefiles could go in this way, transformed at runtime to something that uses Rules.make. Anyone want to write such a parser? You'd call it from Rules.make. The hardest part would probably be getting the vmlinux link right - kbuild25, being non-recursive, doesn't have to worry about intermediate linking of a master object file in each directory. The first thing that should be sent independently to Linus is probably the asm-offsets stuff. It is mostly independent of the makefile structure. Peter ___ 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
