Hi Joey,
Plus, it's very slow to compile and build archives for a billion modules that are be unrelated to your platform. I agree KConfig seems like an obvious choice and I'm willing to work with you in making these changes.
Nice to hear. So the following steps need to be done:
* Port the Kconfig tool from linux or busybox, so that is build and called from the Makefile framework of U-Boot. * Extract all CONFIG_ and CFG_ defines from the sources and put them into related Kconfig files (e.g. cmd_foobar.[ch] -> cmd_foobar.kcfg), using dummy templates for each extracted CONFIG/CFG define. This can be automated by a script and created lots of small files. * Fix and cleanup all these *.kcfg fragments - this will be the big work! It requires to setup the right Kconfig type, default and inter-dependancies between them. Also some sufficient help text is a must. * Move and rearrange the *.kcfg fragments to form a logical tree of options. Kcfg files might be merged together where appropriate to avoid hundreds of small files. * Use make menuconfig to clone all values from your platform header file. Store the created .config file as your default config. * Create and split autoconfig headers, so that only those sources are rebuild whose defines got changed.
All this could be done in parallel, so that the autoconf.h headers would be created but not yet used. Later you comment all stuff in your platform config and include the autoconfig stuff instead.
The difficult step is the migration from the old platform headers to the autogenerated stuff, as this required somebody to test the platform - we don't to break working platforms.
Any additional thoughts?
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.265 from 18.06.2007 Virus news: www.antiviruslab.com