[LWN Logo]
[LWN.net]
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