Hallo,
No, this is NOT what I mean. "include" means that the information is distributed over at least two files, one of them auto-generated, which makes things just worse.
Maybe we talking about the same thing. All information should be configured with a Single frontend, and the data is saved into a single file. And from this single file a single header might be created (autoconf.h) or for improving the rebuild behaviour this File might be post processed and split into separate files. So each subsystem just includes Related defines, and only subsystems with changed config must be recompiled.
The last thing is just a nice feature to save compile time, but it's still a single config file as a source.
The new config system will make all these board headers obsolete and replaces them by default configs for each supported target.
That's my goal with the new config system.
The whole default configuration is unique for a board.
Yes, and for each board a <boardname>_defconfig will reside in include/configs. The former <boardname>.h file can be deleted, as all information from this file is now auto-configured from the defconfig file.
That was what I wanted to point out. Your previous posting sounded as if you expect a few lines of grep and sed trickery would do all the work ;-)
No, way :-) This will become some nice handwork. Maybe some people will help a bit. See it positive, I get a chance to cross-read most of the current sources to figure out meaning and dependencies of defines. This will for sure help me for future U-Boot ports.
That "<full regression test>" is actually the fun part :-(
Yes, it means to have 100dreds of toolchains at hands and maybe a computer cluster at hands :-) But this issue can be discussed when we are ready for such test.
I don't. I'm an engineer. I always try to recognize where it makese sense to stop. See below.
Sure. This is my every-days life as well. But when the current config system reaches ist limits, it might be much more work to do the necessary step.
Or the project will split into smaller or new projects to reduce complexity. I would prefer to have a single bootloader project available for all existing targets - so I can benefit from the common parts and features everywhere.
I still remember the times where we had different bootloaders for all and everything. I don't want that back.
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.268 from 20.06.2007 Virus news: www.antiviruslab.com