On Sat, 29 Jun 2002 09:26:01 +0200, Sam Ravnborg <[EMAIL PROTECTED]> 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. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
