[CCs trimmed]
[Sam Ravnborg] > > 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 Agreed. It looks like Kai is close to that point. Actually VPATH does all the work for you if you let it, though it looks as though Kai (along with kaos) is taking a more manual approach to get more control. (Come to think of it, VPATH can almost do shadow trees - though it would fail to comprehend different layers of Makefiles.) > > 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. [Greg Banks] > 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. Ah, but note that the Linux kernel build does *not* use autoconf or automake. Why not? Because the platform *is* seen as fixable after all. If your old, weird platform has <strings.h> instead of <string.h> - tough, you'll have to fix your platform before you compile mkdep.c or split-include.c. If you don't happen to have a perror() - tough again. We assume not only a decent ANSI C compiler - we assume a specific range of gcc versions. Etc. > > 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. There is that. But if you regard "cobble together a build-only source tree" as the first stage of your build process, this shouldn't be a problem. > > > [...] In some (most?) SCM systems, the checkout process on a > > > file resets the timestamp to when it was checked in. > CVS does this. Maybe there's a way to turn it off, I don't know. Huh? Not for me. It sets current time on anything *I* check out. Maybe there's a way to turn that screwy feature *on*.... > I agree with Keith, shadow trees rock. I think they are probably > the single most useful feature of kbuild 2.5. I'll have to take your word for it - I guess I'm still at Keith's early stages where he was arguing against them before seeing how useful they apparently really are. Peter ------------------------------------------------------- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
