Hi,
Please be careful when planning for this. One feature thatis essential to me is that it must be possible to have all information for the configuration of a certain board in a single configuration file (i. e. something corresponding to what we have in include/config/<board>.h now)
That is exactly, what I have in mind. The current include/config/<board>.h files will include the autogenerated autoconf.h file (or better a tree of such files, so that build dependancies are only triggered for those submodules whose configs have changed.)
Only those defines, which are unique for the target board will remain in the include/config/<board>.h file.
This can be automated by a script and created lots of small files.
Again, be careful. Ther eis a lot of #ifdef and Makefile trickery in handling the CONFIG_ and CFG_ definitions, and if you try to approach this with a script, then it will *not* be a simple one. Also, "lots of small files" is something that probably is not an improvement.
I fear, that the scripts can produces only templates for the Kconfig files to reduce typing work. All the interactions and dependancies must be added by hand later. Also the help stuff must be filled in by hand. On the other hand, this has the advantage, that most sources are reviewed and maybe rearranged, while the Kconfig files are worked out. Of course the amount of Kconfig files should be reduced to a minimum.
With some careful planning, the Kconfig system can be setup in parallel to the on-going work. The first step could be to have a working Kconfig system which basically defines an empty menutree with nearly no options. All target headers get patched to include these autogenerated headers. <full regression test>.
Now the most common defines will be moved from the headers to some kconfig entry, e.g. the CONFIG_<boardname> define is a good candidate. So more and more common defines will move into the config system. At the end only the single use and board specific defines are left.
Maybe there is a somewhat less perfect, but simpler approach to implement only a 90% or 95% solution with much less effort?
Effort is relative :-) U-Boot is growing fast, and soon there might be much more platforms. Linux and Busybox proof that a sophisticated config system can scale with large projects - and any simpler solution might lack this property and must be replaced later by some 'better' thing. Then all work needs to be redone again.
So I prefer the a 100% solution ;-)
Regards Carsten
____________ Virus checked by G DATA AntiVirusKit Version: AVKA 17.248 from 15.06.2007 ____________ Virus checked by G DATA AntiVirus Version: AVKB 17.267 from 19.06.2007 Virus news: www.antiviruslab.com