Hi,
The upstream xen-unstable.hg[1] tree has recently done away with the
sparse tree. Instead, there's now a new linux-2.6.18-xen.hg[2] tree
that contains a Linux tree modified with the changes from the old sparse
tree. Likewise, the staging repository is now split in two[3][4]. When
you build from the xen tree, the build scripts will make an attempt to
find a valid linux-xen tree to use (looking in ./ or ../ paths as it did
for linux tarballs previously) or using 'hg paths'.
Unfortunately for the architecture ports, this means that a clone of
http://xenbits.xensource.com/ext/xen-ia64-unstable.hg will try to find a
linux-xen repo at http://xenbits.xensource.com/ext/linux-2.6.18-xen.hg.
This doesn't work very well for supporting multiple architectures from
the /ext path. Instead, what we've decided to do is move the ia64 and
ppc ports into their own sub-directories and standardize the names. We
now have a xen-unstable.hg[5] and linux-2.6.18-xen.hg[6] hg repositories
under the http://xenbits.xensource.com/ext/ia64 path. Using these, a
build of the architecture specific xen repository will pull in the
architecture specific linux-xen repository as well.
On the backend, this new ext/ia64/xen-unstable.hg link is pointing to
the same ext/xen-ia64-unstable.hg mercurial tree, so clones and pulls
from either the old or new locations will work fine and they will always
be synchronized. However, after the next pull of upstream, builds will
start to look for the new mercurial linux-xen tree and won't find it.
You can work around this by pre-seeding the linux-xen mercurial tree
into your working tree, but the long term plan is to move to the
ext/ia64 trees to allow the right thing to happen automatically.
If you develop like I do and keep a local mirror of the upstream
trees which you locally clone, here's the "best practices" suggestion I
will make - layout your local copies in a directory structure that
matches upstream. For instance, in your ~/xen-upstream directory (or
wherever you keep your pristine upstream clones), you might have this:
xen-unstable.hg
linux-2.6.18-xen.hg
staging/xen-unstable.hg
staging/linux-2.6.18-xen.hg
ia64/xen-unstable.hg
ia64/linux-2.6.18-xen.hg
These represent the two upstream trees, the two staging trees, and the
two ia64 trees respectively. If you do a local clone of a
xen-unstable.hg tree from one of these, the build scripts will
automatically determine the path the tree came from and pull the correct
linux-xen tree to match.
If you clone your trees from a remote mirror with a static 'hg serve'
running on a port (ex. http://local.server.com:8000/) a 'make world'
will fail because it won't be able to find the linux-xen tree. Again,
this can be worked around by pre-seeding the linux-xen tree, but a
better solution would be to make use of the hg cgi web interface so that
you can replicate the directory structure.
For upstream and staging, these trees are already in place and
active. For ia64, the trees are in place, but until we pull from
upstream we're still making use of the built-in sparse tree. As soon as
we have patches ready to fix the ia64 build on the staging tree (Thanks
for working on this Isaku), I'll do the pull that will bring us in sync
with the new build process. After that point, patches that affect the
linux-xen tree should be sent separately from patches affecting the xen
tree, but I will continue to take ia64 patches for both. Please let me
know if you have any questions. Thanks,
Alex
[1] http://xenbits.xensource.com/xen-unstable.hg
[2] http://xenbits.xensource.com/linux-2.6.18-xen.hg
[3] http://xenbits.xensource.com/staging/xen-unstable.hg
[4] http://xenbits.xensource.com/staging/linux-2.6.18-xen.hg
[5] http://xenbits.xensource.com/ext/ia64/xen-unstable.hg
[6] http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg
--
Alex Williamson HP Open Source & Linux Org.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home