On Sun, 23 Jun 2002 22:14:58 +0200, Sam Ravnborg <[EMAIL PROTECTED]> wrote: >On Sun, Jun 23, 2002 at 11:54:29PM +1000, Keith Owens wrote: > >> Linus and Kai do not think that shadow trees are useful. I have given >> up explaining why they are useful. Now I am waiting until Kai hits a >> dead end using the current syntax (there is no way that the current >> syntax can cope with shadow trees) then I will try to raise some >> interest in using the new syntax to get the advanced features of kbuild >> 2.5. > >Hi Keith. >To me the functionality provided by kbuild-2.5 with respect to shadow >trees belongs to the SCM system. >What kbuild-2.5 address is only the simplest part namely the compile step. >A proper SCM system allow you to do parrallel development with a >seperate integration branch, or whatever term the SCM in question >like to use.
Compiling from an SCM system only works if everybody uses the same SCM tool, that is not an option for the kernel. kbuild 2.5 works for everyone, no matter what other tools the developer uses. Some architecture dependent code is not in Linus's tree because it requires changes to common code that will break other architectures. For a long time you could not apply the ia64 patch to the kernel then compile for other architectures, the other architectures would break. Merging change sets for arch dependent code is a problem for any SCM. I was using PRCS for my kernel work long before BK came along, it has patch sets and branches with good tools for merging changes together. Larry has said that PRCS is one of the best SCM's other than BK, it is only the lack of a distributed repository that stopped PRCS being used more widely. Even with a decent SCM like PRCS, handling multiple patches and testing all the combinations is a nightmare. I was working on ia64, xfs and kdb and had to ensure that these patch combinations worked :- Standard kernel Standard + ia64 Standard + ia64 + xfs Standard + ia64 + kdb(ia64) Standard + ia64 + xfs + kdb Standard + xfs Standard + kdb(i386) Standard + xfs + kdb Without shadow trees, I had to maintain 8 separate source trees to support those combinations. Any xfs change had to be manually replicated over 4 trees, any ia64 change had to manually replicated over 4 other trees. Any change to the standard kernel had to be manually replicated over all 8 trees. kdb was even worse, it consists of arch independent patches plus arch dependent patches. kdb has to be done that way because some of the kdb arch patches go over other arch patches that are not in base kernel. Add devfs to that mix and you need at least another 7 trees. Manually tracking and replicating changes across multiple source trees takes far too much time and is error prone. Using an SCM introduces its own set of problems. You are hacking away, you decide that a change was a mistake and you want to revert to the SCM version of that file. In some (most?) SCM systems, the checkout process on a file resets the timestamp to when it was checked in. Standard 'make' processing cannot cope, it expects timestamps to always go forward, not backwards. kbuild 2.5 tracks all timestamp changes. Another set of problems with an SCM is separating the change sets when you are satisfied with the updates and you do the check in. With two or more change sets in the same source tree, how do you do a check in as separate change sets? Once you mingle two change sets in the same source tree, splitting again is extremely messy and error prone. It is far better to keep them separate in the first place. An SCM might work for just one set of changes (ignoring the checkout timestamp problem). It falls down when you are working on multiple change sets, expecially when they are arch dependent. When shadow trees were first suggested I argued against them, but experience has shown that they are better than an SCM system. For ia64 + xfs + kdb I keep one copy of the sources for the standard kernel, ia64, xfs and kdb (i386 and ia64) then use shadow trees to mix and match all the combinations, each combination has its own object tree. Each change set is kept separate and can be checked in and out separately, without worrying about timestamp problems or manual replication of changes. ------------------------------------------------------- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
