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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/