On Mon, Jun 24, 2002 at 08:49:34AM +1000, Keith Owens wrote:
> 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.
This does not make sense.
The kernel is distributed in two ways today. As diff patches as usual
and as BitKeeper repositories.
The diff patch version allow you with some tweaking to import new kernels
to virtually all SCM systems that is suitable for kernel development.
There is absolutely no requirement that all kernel developers uses
the same SCM system.
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
[Some SCM systems likes it like this, others are less restrictive.
Some developers likes it likes this as well].
When starting to use a SCM system the developer gets all the
functionality provided by such a tool with respect to parrallel
development etc.
[snip]
> 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.
All the above look like ordinary problems for me, and we can
only agree that some kind of tool support is needed during daily work
with this amount of different trees.
So the point for discussion is solely:
a) Where is this functionality best located
b) How to implement this
I have seen NO discussion of the above items so far. Therefore I bring it
up now together with my opinions.
Shadow tree functionality
=========================
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.
How to implement shadow trees
=============================
within the SCM tool.
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.
Then combine this with a wrapper around kbuild, and viola, support
for shadow trees.
No magic in kbuild, no need to complicate a tool used by so many
others.
> 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.
I have worked with the following SCM systems:
RCS, Clearcase, BitKeeper
None of them had this BUG! They had the possibility to do it, but
it was clearly mentioned in the Documentation that it could confuse
make.
There is no reason to add a lot of complexibility to kbuild,
to cover malconfiguration in SCM tools.
> 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.
In Cleacase I just establish two different views. No problem.
I BitKeeper I just execute bk clone twice. No problem.
So I do not recognize the problems that you describe above.
But it could be me that is unfamilar with CVS, PRCS, arch, ???
> 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.
How big effort is required to implement support for shadow trees
outside kbuild?
Sam
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
