From: Keith Owens <kaos@ocs.com.au> To: kbuild-devel@lists.sourceforge.net Subject: [kbuild-devel] kbuild-2.5 shadow trees Date: Sun, 01 Apr 2001 06:45:24 -0700 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii kbuild 2.5 supports three build models. (1) Source and object in the same directory. This is the existing model and will suit most end users. It is the default. (2) Source and object in separate directories. You can define a separate object directory for each set of config options, e.g. SMP vs UP, i386 vs ia64, monolithic vs modules. The source tree becomes completely read only, apart from last access timestamp changes, in particular all the 'touch include/foo.h' commands have gone. All the source is in one tree, including all patches and add on software. This model will suit people who need to compile with different configs but do not do much development work. They apply the patches they need and compile for multiple configs. (3) The kernel is constructed from multiple source trees and built in a separate object tree. As for (2) you have a separate object directory for each set of config options. But instead of manually building a single source tree from various patches, the patch sets are kept separate and kbuild 2.5 logically constructs a single kernel source tree from the various source trees. This is called a shadow tree system because the patch sets shadow the main kernel source tree. This model is aimed at kernel developers who have to maintain more than one set of kernel patches. Most of this mail concentrates on shadow trees. Shadow trees are sparse, they only contain the files that the patch set creates or updates. In general if a shadow tree needs to update a file in a lower tree then the shadow tree contains a complete copy of that file. If a shadow tree defines the only copy of a file (e.g. all of fs/xfs) then there are no problems with overlapping changes. When two or more shadow trees hit the same file then you have to resolve the overlap. Earlier I said "in general if a shadow tree needs to update a file in a lower tree then the shadow tree contains a complete copy of that file". Several files are hit by every reasonable sized patch set, the obvious example is Configure.help. Maintaining these files would be a problem, but fortunately the order of entries in these files does not matter. kbuild 2.5 recognises shadow files suffixed with '.prepend' and '.append' and prepends or appends their contents to a copy of the base source file. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE6xzD0i4UHNye0ZOoRAofjAJ90VeiA7js06QGnl3PLOh2KoS9vnACgkA6V /x97G5roLHS9HN/ms+Sdc4w= =mAJT -----END PGP SIGNATURE----- _______________________________________________ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/kbuild-devel