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.
>
> This functionality is foreseen useful for both current kbuild and kbuild-2.5
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:
xsource ()
{
builtin source $srctree/$1
}
shopt -s expand_aliases
alias source=xsource
So the scripts do not even need to know about object directory and source
directory, they only need to know that there is a source directory which
can be separate from the current directory. This behaviour is closer to
the way autoconf behaves with a separate object directory.
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.
On Fri, 28 Jun 2002 18:07:45 +1000,
Greg Banks <[email protected]> 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.