G'day, I'll just briefly unlurk on the subject of kbuild before getting back to the kconfig bughunt.
Sam Ravnborg wrote: > > On Mon, Jun 24, 2002 at 08:49:34AM +1000, Keith Owens wrote: > > [...] > There is absolutely no requirement that all kernel developers uses > the same SCM system. Agreed. But this means that when dealing with the kernel build system we need to plan for the case where someone is working in a workarea built from a combination of two or more trees, partial trees, or patches from different sources kept in different SCMs. So we need to plan for the lowest common denominator in SCM systems, which is none at all i.e. getting a bunch of tarballs from ftp.kernel.org and elsewhere. > Obviously the kernel build system should work for everyone irrespective > of the SCM system in use. This put at least the following demands: > 1) Separate OBJ and SRC tree > 2) That kbuild does not touch any files in the SRC tree Yes, this is the absolute minimum useful behaviour for a build system. For example autoconf/automake work this way in user space. Note that kbuild 2.4 doesn't work this way (or at least it didn't before Kai got started). > > Without shadow trees, I had to maintain 8 separate source trees to > > support those combinations. [...] Manually > > tracking and replicating changes across multiple source trees takes far > > too much time and is error prone. > All the above look like ordinary problems for me, and we can > only agree that some kind of tool support is needed during daily work > with this amount of different trees. > > So the point for discussion is solely: > a) Where is this functionality best located > b) How to implement this > > I have seen NO discussion of the above items so far. Therefore I bring it > up now together with my opinions. Fair enough. > Shadow tree functionality > ========================= > The functionality to support shadow trees are best located in an SCM tool. > If the developer or group in question does not use a SCM tool - or maybe > a non-coherent setup with two different SCM tools then there is a need > to support this at another place. > The best place is in between the kbuild and the trees managed. Sure, this is basically an SCM problem, and in an ideal world would be handled by the SCM tool and kbuild itself would just see a unified view of files. However in the real world we need to plan for the case where the SCM is too dumb to do this and too (ahem) precious to be fixed to do this, or even nonexistant, so we end up having to do it in kbuild. This is the same reason why we have the extraordinary complexity of autoconf and automake for usermode programs: it's regrettably necessary to deal with imperfect and unfixable platforms. > How to implement shadow trees > ============================= > within the SCM tool. > It no SCM tool is used then a simple script that takes all updates > from one or more separate SRC trees and copy them to a common place > could do it. And then afterwards we've got to untangle this mess again, completely reliably and automatically. The beauty of having proper shadow trees is that the trees are kept completely separate at all times except in the compiler. There is *no* danger of ending up sending the wrong patch to the wrong place or checking the wrong file into the wrong SCM. > > [...] In some (most?) SCM systems, the checkout > > process on a file resets the timestamp to when it was checked in. > I have worked with the following SCM systems: > RCS, Clearcase, BitKeeper > None of them had this BUG! CVS does this. Maybe there's a way to turn it off, I don't know. > > Another set of problems with an SCM is separating the change sets when > > you [...] do the check in. [...] > In Cleacase I just establish two different views. No problem. > I BitKeeper I just execute bk clone twice. No problem. > So I do not recognize the problems that you describe above. > But it could be me that is unfamilar with CVS, PRCS, arch, ??? It is a problem with every SCM too dumb to know about change sets, in particular CVS. Remember, CVS is used by everyone too poor for ClearCase and too cautious or oldfashioned for BK. > > When shadow trees were first suggested I argued against them, but > > experience has shown that they are better than an SCM system. I agree with Keith, shadow trees rock. I think they are probably the single most useful feature of kbuild 2.5. I fervently hope we end up with shadow trees or something like them by the end of Linux 2.5. Greg. -- the price of civilisation today is a courageous willingness to prevail, with force, if necessary, against whatever vicious and uncomprehending enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001. ------------------------------------------------------- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
