Re: [kbuild-devel] [PATCH] kconfig: menuconfig and config uses $objtree

Greg Banks
2002-06-28T09:16:04Z

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.