On Mon, Jun 24, 2002 at 12:41:28AM +0200, Arnd Bergmann wrote:
> > Why do you see so much added value in kbuild support for shadow trees
> > compared to what a proper SCM tool give you?
>
> For my (linux on s390) purpose, shadow trees are the most important
> feature of kb25, because they allow us to use a proper SCM at all.
> Currently, we use a CVS repository that includes the official Linux tree
> as well as our closed source drivers. I would love to use Bitkeeper, but
> that's only possible if we can easily seperate the free from the the
> nonfree stuff without having two complete (incompatible) repositories.
> Shadow trees allow just that.
So basically you need a tool to merge two directory structures without
touching unchanged files.
You could say that this is what you get for free in kbuild-2.5.
But I do not see this as part of the kernel build system.
Do you need this feature then create a small script that do exactly what
you need and run it before the build process.
The script should basically just copy modified files to the build tree.
My point is that the kernel build system should not be cluttered
with functionality that belongs in supporting tools.
Hmm, and I did not see why you could not use BitKeeper or some other SCM
for both the free anf non-free stuff?? A matter of dollars to spend?
> For most other people, the added value is that they don't have to use
> the same SCM tool as anyone else. Giving the user a tarball with
> a driver (or multiple ones, for that matter) is just so much easier
> than telling him/her how to patch the source with all things that can
> go wrong there.
When the functionality in question touches common files this approach
does no longer work. Therefore keep half solution out of the kernel build system.
Sam
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
