From: Greg Banks <gnb@alphalink.com.au>
To: Keith Owens <kaos@ocs.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 19:16:20 +1000 [thread overview]
Message-ID: <3D1C2964.2D245607@alphalink.com.au> (raw)
In-Reply-To: 934.1025254697@ocs3.intra.ocs.com.au
Keith Owens wrote:
>
> 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. [...]
>
> You are still forcing all the CML code to know about the difference
> between source and object trees and to handle multiple source trees.
Yes.
> With that approach, the knowledge has to be embedded in every CML
> program, and changed every time the tree structure changes.
I haven't commented on whether Sam's patch is good architecture, just
that it could be implemented in several hundred fewer lines.
> 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.
Sure. Assuming Sam's script will take the source director(y|ies) as an
argument, they will work with this approach but they will also work with
whatever approach Kai takes.
> 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.
Great, another reason to use kbuild 2.5.
Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.
prev parent reply other threads:[~2002-06-28 9:16 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
2002-06-28 9:16 ` Greg Banks [this message]
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=3D1C2964.2D245607@alphalink.com.au \
--to=gnb@alphalink.com.au \
--cc=kai@tp1.ruhr-uni-bochum.de \
--cc=kaos@ocs.com.au \
--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