> Does it make sense to introduce limited support for the drivers.conf idea
> in kbuild-2.5 already now?
kbuild-2.5 is big enough to already be a problem to be accepted
'all in one go'. Adding driver.conf support will just make this problem
bigger. What Keith has already needs to somehow be done gradually.
How this happens isn't exactly obvious to me however. Due to the way
things like dependancy calculation have changed, you can't for example
do the merging on a per-directory basis and say "drivers this time",
"now the filesystems" etc..
Whilst kbuild2.5 lives happily with the old kbuild still being in the
tree, it doesn't support building one dir with newstyle, and another
with oldstyle. I don't even want to *think* about whats involved to
make that work, and I imagine Keith doesn't either.
> The first step could be to support it in kbuild, next step could be to support
> it in for example "make config" or even better mconfig from Michael Chastain.
Don't confuse the build system with the configuration system.
Whilst they are somewhat intertwined, they are not dependant on each other.
> IMHO it would also be plain stupid to put a lot of effort in
> supporting the old makefile syntax, when the files are already converted.
That effort has already been done. kbuild2.5 can live alongside the
existing build system.
> --
> Those that can, do. Those that can't, troll on linux-kernel.
Sadly, all too true these days.
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
_______________________________________________________________
Hundreds of nodes, one monster rendering program.
Now that's a super model! Visit http://clustering.foundries.sf.net/
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
