public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Keith Owens <kaos@ocs.com.au>
To: Greg Banks <gnb@alphalink.com.au>
Cc: Sam Ravnborg <sam@ravnborg.org>,
	Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>,
	mec@shout.net, kbuild-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [kbuild-devel] [PATCH] kconfig: menuconfig and config uses $objtree
Date: Fri, 28 Jun 2002 18:58:17 +1000	[thread overview]
Message-ID: <934.1025254697@ocs3.intra.ocs.com.au> (raw)
In-Reply-To: Your message of "Fri, 28 Jun 2002 18:07:45 +1000." <3D1C1951.987E1FF8@alphalink.com.au>

On Fri, 28 Jun 2002 18:07:45 +1000, 
Greg Banks <gnb@alphalink.com.au> wrote:
>Sam Ravnborg wrote:
>> 
>> In order to prepare for separate obj and src trees make use of $objtree
>> within scripts/Menuconfig and scripts/Configure.
>> All temporary and all result files are located in directory pointed at
>> by $objtree.
>
>Interesting, but there's an alternative approach.  Let the scripts dump
>any files they like into the current directory, but move the current
>directory to be the *object* directory not the source directory.  Then
>all you need to change are the places where the arch config.in files are
>initially included, and to override the "source" statement to look relative
>to $srctree not the current directory.  That last can be done like this:

You are still forcing all the CML code to know about the difference
between source and object trees and to handle multiple source trees.
With that approach, the knowledge has to be embedded in every CML
program, and changed every time the tree structure changes.

It is far better to retain the existing CML design which assumes that
there is only one tree.  Then use symlinks to hide the real tree
structure from CML.  That gives us the flexibility to change the tree
structure without changing every CML program.

Notice that kbuild 2.5 handles separate source and object trees and
even multiple source trees with _no_ changes to CML code.  The only
change to CML in kbuild 2.5 is to add Ghozlane Toumi's extra config
targets.  scripts/Makefile-2.5 hides all the complexity of separate
source and object and multiple source trees from both CML1 and CML2.


  reply	other threads:[~2002-06-28  8:56 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
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 [this message]
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=934.1025254697@ocs3.intra.ocs.com.au \
    --to=kaos@ocs.com.au \
    --cc=gnb@alphalink.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