public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Keith Owens <kaos@ocs.com.au>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>,
	mec@shout.net, kbuild-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kconfig: menuconfig and config uses $objtree
Date: Sat, 29 Jun 2002 18:23:00 +1000	[thread overview]
Message-ID: <7026.1025338980@ocs3.intra.ocs.com.au> (raw)
In-Reply-To: Your message of "Sat, 29 Jun 2002 09:26:01 +0200." <20020629092601.A2019@mars.ravnborg.org>

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.

  reply	other threads:[~2002-06-29  8:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-27 22:14 [PATCH] kconfig: menuconfig and config uses $objtree Sam Ravnborg
2002-06-28  2:19 ` Keith Owens
2002-06-28 17:28   ` Sam Ravnborg
2002-06-29  1:50     ` Keith Owens
2002-06-29  7:26       ` Sam Ravnborg
2002-06-29  8:23         ` Keith Owens [this message]
2002-06-30  9:31         ` [kbuild-devel] " Greg Banks
2002-06-29 15:36       ` Roman Zippel
2002-06-28  8:07 ` [kbuild-devel] " Greg Banks
2002-06-28  8:58   ` Keith Owens
2002-06-28  9:16     ` Greg Banks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7026.1025338980@ocs3.intra.ocs.com.au \
    --to=kaos@ocs.com.au \
    --cc=kai@tp1.ruhr-uni-bochum.de \
    --cc=kbuild-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mec@shout.net \
    --cc=sam@ravnborg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox