On Sat, 29 Jun 2002 09:26:01 +0200,
Sam Ravnborg <sam@ravnborg.org> wrote:
>So in our discussion about shadow-tress I recall you mentioned
>several times that using a built-only tree of src-files would create
>a lot of problems when changes were made, and you had to distribute
>changes back in the original trees.
>My point then was that changes were always made in the original tree.
>And now I see that you use the exact same apporach for config-files
>within kbuild-2.5. So do you agree that creating a built-only tree
>suddenly becomes an OK solution?
You are confusing two completely different cases. Config reads from a
lot of files and generates one file. Kernel build both reads and
writes lots of files, plus the developer edits files as they create
their code. Different problems require different solutions.
Creating a set of symlinks in the object tree to point to every source
file is possible but horribly slow! On my build machine, creating
10,300 symlinks takes 90 seconds before you can even start compiling [*].
In contrast, all of the kbuild 2.5 processing (phases 1 through 4) on
the same machine takes 9 seconds before you start compiling.
I use symlinks for CML because there are far fewer files and the
symlink tree only has to be built when make *config is requested.
There are also several CML programs that would have to be changed each
time the tree structure changed, code replication is bad.
I do not use symlinks for the main build because they are too slow.
Especially when you include the overhead of resynchronising the source
symlinks on every build. It has to be redone every time because the
set of source files may have changed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 30 2002 - 22:00:13 EST