In message 46597312D56D2A47A3A6E9C1D0D9B7AEB0C323@kpladc0001.konzeptpark.intra you wrote:
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.)
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.
When I write "a single configuration file" I really mean a SINGLE file, and not collecting the information from several includes.
Only those defines, which are unique for the target board will remain in the include/config/<board>.h file.
The whole default configuration is unique for a board.
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.
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 ;-)
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>.
That "<full regression test>" is actually the fun part :-(
So I prefer the a 100% solution ;-)
I don't. I'm an engineer. I always try to recognize where it makese sense to stop. See below.
Best regards,
Wolfgang Denk